[Seaside] Seaside and GOODS
martin.beck at hpi.uni-potsdam.de
Fri Dec 15 17:23:14 UTC 2006
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?
> 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?
More information about the Seaside