Hang while commiting objects with attribute as MagmaCollection+index

[Chris Muller]

Hi Hilaire, from your first post, you wrote:

> In the Learner initialization if I remove the addIndex:, the process run
> at a constant speed and finish.

Then the initialization code with, presumably, the way that does NOT
exhibit the problem:

IFILearner>>initialize
       super initialize.
       schoolYear := #CE2.
       learningStates := MagmaCollection new.
       learningStates
               "addIndex: (MaCompetencyIndex attribute: #competency);"
               addIndex: (MaFloatIndex attribute: #acquisitionLevel)

If this is the case, please review your MaCompetencyIndex.  It sounds
like it's #indexHashesForIndexObject: may be answering progressively
more "keys" to index by.

Multi-key indexing in the server, despite several good optimisations,
over the years, is a resource intensive operation.  If you try to
index, say, 10000 keys in one commit, you would not see that fact
reflected in the

  'objects'

instance-variable of MaCommitPackage.  Instead you will find it by
exploring the commitPackage's

  'allLargeCollectionChanges'

variable to see all the changes, including all the integral key values
for the server-indexes.  If as many as 10000, that commit will take a
long time.

So yes, it is very good to have the commit in the inner loop.  :)

=======

If you do not find any problem with your MaCompetencyIndex, here is a
template script I put together based on my interpretation of the
problem:

|mc subMc|
mc := MagmaCollection new
	addIndex: (MaIntegerIndex attribute: #key);
	yourself.
subMc := MagmaCollection new
	addIndex: (MaIntegerIndex attribute: #key);
	yourself.
subMc add: 110 ->'subMc'.
mc add: (100->subMc).
MagmaRepositoryController create: 'c:\temp\hilaireTest' root: mc

It commits nested MagmaCollections, each with an index.  Since I do
not have access to your model, perhaps we can work together from this
simple generic example to demonstrate the issue.

 - Chris

On Jan 6, 2008 5:08 PM, Hilaire Fernandes <hilaire at ofset.org> wrote:
>  From the commit:[] of my testcase, I have checked the prepared
> MaCommitPackage instances, its objects size is constant at 30
> objects/1137 bytes, even the one just before the hang.
> The hang happens in :
>
>         commitResult := self submit: ((MaWriteRequest new)
>                                                 package: commitPackage;
>                                                 beginAnother: aBoolean;
>                                                 yourself)
>
>
> and this loop does not finish:
>
> aMagmaRepositoryRequest waitCursor showWhile: [link submit:
> aMagmaRepositoryRequest]
>
>
> I am pretty sure the problem is connected with the creation of indexes
> of the MagmaCollection.
>
> Hilaire
>
>
> Hilaire Fernandes a écrit :
> > Chris Muller a écrit :
> >>>                                         IFIModels users add: user].
> >>
> >> Well, there you go.  Isn't this referencing the entire, ever-growing
> >> database all in memory?
> >
> > Really? I agree about the idea an of ever-growing database but IFIModels
> > users just return the #users branch of the database, which is a
> > MagmaCollection. Nothing special there.
> >
> > What is special is that the added user objects contain itself two
> > indexed Magma collections, and the problem is related to that because if
> > I remove this part there are no problem.
> >
> > Do you have test covering this case usage?
> >
> > I try to read your test, not very easy to follow.
> >
> > Hilaire
>
>
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>