[Seaside] Seaside and GOODS

[Martin Beck]

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

> 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