[Seaside] Seaside and GOODS

[David Shaffer]

Martin Beck wrote:
> Am Freitag 15 Dezember 2006 17:53 schrieb Benjamin Pollack:
>
> Thanks, I'll use that. Didn't know with which solution to go. Another issue 
> is, as stated by someone here, the performance. If I insert for example 14000 
> entries in a batch, the commit is very long (20mins)... Any reason for this?
>
> Greets,
> Martin
>   
The Squeak GOODS client commit strategy is this:

1) Go through all objects in the cache and convert them to a "record" 
representation (a process similar to serialization)
2) Compare the record now to the one originally loaded from GOODS
3) If the records are different send it to GOODS

So, if your cache is large it will take a long time to commit (or 
rollback).  I have substantially improved performance (get the latest 
version from SqueakSource) but it still runs in O(cache size) time.  
BTW, the latest versions on SqueakSource are not compatible with 
WriteBarrier so I haven't made them the "official" versions on SqueakMap 
yet.  I could never get WriterBarrier to work well for me but a correct 
solution to this problem is something like it attempts: catch all i-var 
assignments and mark the corresponding object "dirty".  VisualWorks has 
VM-level support for object immutability which can be used to make a 
more robust "write barrier"...Squeak's implementation of OODB clients 
(especially Magma, GOODS and OmniBase) could be made to be a lot faster 
if the Squeak VM (and image) supported immutability.  That is, assuming 
it can be done with out significantly slowing down assignment.

Just a note regarding your other question: commit failures.  As people 
have suggested, if you are not going to use pessimistic locking you 
probably want to simply re-do the operation that failed after loading 
the modified objects.  I'd just like to add a few thoughts to 
this...Using "command" objects to capture all database modifications can 
make this process cleaner.  If a command fails (due to a commit 
failure), flush your GOODS session and re-execute the command.  If you 
adhere to the command pattern well you can quickly gain other benefits 
from it like undo-able commands, composite commands etc.  The 
disadvantage of this approach is that you want all mutation of objects 
loaded from the database to occur in the commands.  So, if you're 
displaying a user-interface where a object is being edited, you need 
some strategies for either accumulating changes made to that object so 
that they can be captured in a command and/or use some kind of copying 
mechanism to make sure that you don't modify the object that was 
actually loaded from the database.  This can get tedious.  I believe 
that if you read some of the Magma documentation pages you'll get some 
ideas on how to make this work...the ideas are basically the same 
whether you're using GOODS or Magma (although Magma seems to have a 
richer set of concurrency control features).  Another good source of 
information is the Gemstone Smalltalk mailing list.

David