[Seaside] transaction engines?

[Stephen Pair]

Avi Bryant wrote:

>
> On Apr 28, 2004, at 4:44 PM, goran.krampe at bluefish.se wrote:
>
>> radoslav hodnicak <rh at 4096.sk> wrote:
>>
>>> Does anybody happen to know/have an engine that implements transactions
>>> for normal smalltalk objects? No external access or anything needed.
>>
>>
>> Stephen Pair has made one called KATS:
>> http://map1.squeakfoundation.org/sm/packagebyname/kats
>
>
> The thing I don't like about KATS is that it's too ambitious: it tries 
> to have the exact same instances of objects appear to have different 
> state inside different transactions.  This means hacking the compiler 
> so that inst var accesses are actually lookups in the current 
> transaction, which is pretty intrusive.  In Seaside, I don't expect to 
> share instances between sessions, and so having multiple copies of the 
> same object (one per transaction) would be perfectly fine.  These 
> could be brought in as-needed the same way an OODB does - when 
> accessing an object for the first time in a new transaction, all of 
> its references would be stubbed out, and local copies for those 
> objects would be made the first time you tried to send them a 
> message.  Even with nested transactions this would be pretty easy to 
> manage, and a lot easier to debug.   Each transaction would keep a map 
> from the original parent object to the local copy, for use when 
> committing.   If you really needed an instance that lived longer than 
> a single transaction, you could have a proxy that stored a root object 
> and always forwarded its DNUs to the local equivalent in the current 
> transaction - basically the same as the ReusableRef that Cees has 
> mentioned using with OmniBase.
>
> I've wanted to write a transaction engine like that for a while (I'm 
> tired of writing half-assed equivalents that break on edge cases, eg, 
> WAModelProxy), but haven't had time yet.  Rado, if you get started 
> I'll pitch in.
>
> Avi 


Even if you could get Kats working in a recent image, I'm afraid I have 
to agree with Avi.  Of course, Avi's last couple of sentences are 
exactly how Kats got started.  If you travel far down this path, you'll 
soon realize that you really need to make a lot of progress on a lot of 
fronts (instance based behavior, traits, perspectives, deadline based 
scheduling, distributed timing, etc) to arrive at a system that is 
usable without losing your sanity.  And, even then, to make it perform, 
you may have to think about an entirely new VM (see Chango), at which 
point you might start thinking about new techniques in VM construction.  
Chango is essentially the successor to Kats, with a distributed OODB in 
the mix and a modified VM that has similar capabilities to LOOM (though 
very different in its motivations and goals)...the version of Kats in 
Chango is quite a bit evolved from the version on SqueakMap.

You may want to read up on Croquet...at its heart is a system to handle 
distributed object replication and synchronization (which necessitates a 
"transaction engine").  I got to a point with Chango and realized that 
to get to a really usable system would take me years to accomplish and 
lots of trial and error (especially given my limited time...it was sort 
of like scaling a mountain only to discover from the vantage point of 
its peak that there is an entire range of mountains that will have to be 
scaled to reach the destination).  Since Croquet is addressing all the 
same issues (and many more), I hope to eventually rebuild Chango using 
Croquet.

- Stephen