[Seaside] Persistent object framework

[C. David Shaffer]

Avi Bryant wrote:

>
> On May 13, 2004, at 8:04 AM, C. David Shaffer wrote:
>
>> Rather than having to tell the index to "update" why not have a two 
>> phase commit in KKRecordCache>>commitObject:?  You could send 
>> "goodsAboutToCommit" to all dirty objects and then you could have a 
>> default impl to update all indices.  Then you'd have to make a second 
>> pass to ensure that all of the dirty objects are really being 
>> committed.  I have some OmniBase code which does this kind of thing.  
>> I was fairly minimal but it did avoid updating indices when the "key" 
>> didn't change.  If you don't see any problems with this then I'll 
>> bring it over to Squeak and rework it for GOODS.
>
>
> Sounds good, though I'm concerned about performance with the two pass 
> commit.  GOODS does a full pass through any loaded objects to check 
> them for changes; this is the main cost for a commit, and doubling it 
> would be bad.  We only really want the second pass to look at the 
> index objects, but how do we restrict it to that without really ugly 
> special casing?


OmniBase uses a write barrier so it isn't very expensive there.  I can 
see that it would be costly with GOODS and I don't see a way to avoid 
that without the cost of requiring some explicit write barrier such as 
the update mechanisms being discussed.  I suspect that GOODS sits on the 
performance fence to due this scanning so I'd hate to push it over.  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.  Maybe some kind 
of nested session which caches objects needed during the first phase and 
only searching those for changes.  Again, the implementation doesn't 
jump out at me.

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.

David