Magma on 3.7 report

[Bert Freudenberg]

Am 25.03.2006 um 21:12 schrieb Chris Muller:
>  Equally important, how much to keep in memory by hard-referencing  
> or not.  Hard referencing the root for example will cause all parts  
> of the database explored to remain in memory, growing and growing  
> endlessly.  This may be tempting to do so that objects don't have  
> to be "reread" but it also causes the dictionary's to get very big  
> and slow.  Were it not for MaWeakValueDictionary replacing  
> WeakValueDictionary, the "objects" dictionary becomes unusable  
> after just a couple hundred-thousand entries or so..

My "objects" are a plain WeakValueDictionary ... do I need to switch  
something on?

>  Management of the size of the in-memory domain model is also  
> helped by #stubOut:.  Magma does not call this itself, it is a tool  
> for the developers discretion.  It involves a becomeForward: so the  
> best thing to do is, for example, stub the single Collection of  
> 6000 objects, not each of the 6000.  I don't think multiple Seaside  
> sessions referencing an object you stubOut: should be a problem  
> although may be good idea to guard it with a Mutex.

What if another session modifies something while a commit is in  
progress? Could this lead to problems? I guarded the commitAndBegin  
in a mutex, though.

>  Having said all this, though, your "straight port" to Magma, from  
> the all-in-memory approach may still be workable if you can endure  
> the initial "load time" of the model into memory (90% of which is  
> probably building those darn dictionary's).  Just be sure to KEEP  
> it all in memory after its gone through all the trouble..  :)   
> Commits will probably slow down so if they get too unbearable you  
> could always turn on WriteBarrier.

Would using WriteBarrier be as simple as "myMagmaSession  
allowWriteBarrier: true"? What drawbacks are there?

- Bert -