[Seaside] Persistent object framework
Avi Bryant
avi at beta4.com
Fri May 14 21:06:40 CEST 2004
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
More information about the Seaside
mailing list