Re: Persistent object framework

On May 13, 2004, at 6:27 PM, C. David Shaffer wrote:
>   One thing you could do is require that #goodsAboutToCommit return 
> the roots of potentially changed objects (the indices) and only look 
> at those.  I'm not sure how to make this work since the roots might 
> look like their momentos but some object further down could be 
> changed.

Right, it's not the index objects but the individual BTreeNodes or 
whatever.  And so there's no good way for #goodsAboutToCommit to know 
exactly which object to return...

> I know that Gemstone/S uses immutability to implement transparency 
> caches in Smalltalk's that support it...otherwise you can either 
> explicitly mark your objects dirty or use a special compiler.  
> Pre-immutibility support in VW I went the explicit route since it 
> seemed the lesser of the two evils.

Yeah, I'd love some kind of a transparent write barrier (ie, 
immutability bit).  We may get it with Squeak VI4, but in the meantime 
the scanning seems the best way to go.  Unless you have any brilliant 
suggestions?

How does the explicit marking work in Gemstone?  In  OmniBase you just 
mark a "cluster", so it works pretty well for eg Dictionary in that you 
only have to mark the top level object and not the individual 
associations.  Does Gemstone work roughly the same way?

Avi