[Seaside] Seaside and GOODS

[Benjamin Pollack]

On 12/15/06, Ramon Leon <ramon.leon at allresnet.com> wrote:
>
> > Hey, do you have any experiences with Seaside, GOODS and
> > heavy traffic on the server?
> > I hold a GOODS connection for every session and close it,
> > when the session is closed. However, it seems, that GOODS has
> > problems with concurrency. For example:
> >
> > Client 1: read,     , change,       , commit
> > Client 2:     , read,       , change,       , commit
> >
> > This gives a KKCommitFailure at the second commit (i think).
> > Especially with BTrees and TSTrees this can be a huge
> > problem. How do other object oriented database solve this
> > locking and transaction things?
> >
> > Regards,
> > Martin
>
> Isn't this exactly the expected behavior?  This is standard optimistic
> locking, first commit wins, so where's the issue?


Right, but understanding how to work with optimistic locking the fist time
can be a bit confusing. If you're using a BTree for your a big data
structure, then following can error, which confuses a lot of people
(including me when I first was getting started):

Session 1: db root at: 'baz' put: 'frob'.
Session 2: db root at: 'bar' put: 'cow'.
Session 1: db commit.
Session 2. db commit -> KKCommitFailure

You've got two solutions:

   1. Lock the object before you make the change. This can be done with
   KKDatabase>>writeLock: and KKDatabase>>readLock: and friends. This is the
   wrong solution for nearly everything, but it's nice to know it's there when
   you need it.
   2. Put your change to the tree inside a KKDatabase>>commitWithRetry:
   block. commitWithRetry simply catches the KKCommitFailure, rolls back any
   attempted changes, and then tries again, repeating until it succeeds. This
   will continue updating your BTree snapshot until the version you have
   matches the version in the db and your insertion succeeds.

On a purely random note, why are all the GOODS database classes prefixed
with KK? Shouldn't it be DB or GO or something?

--Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20061215/3cf0a132/attachment.htm