Seaside and GOODS
Locked
 
|
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 _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> 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? Ramon Leon http://onsmalltalk.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Martin Beck-3
2006/12/15, Martin Beck <[hidden email]>:
> Hey, do you have any experiences with Seaside, GOODS and heavy traffic > on the server? What helps a lot in terms of performance is to install WriteBarrier. Compile the server with GCC 2. Not GCC 3 and not GCC 4. Cheers Philippe > 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 > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Ramon Leon-5
On 12/15/06, Ramon Leon <[hidden email]> wrote:
> Hey, do you have any experiences with Seaside, GOODS and 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:
--Benjamin _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Philippe Marschall
On 12/15/06, Philippe Marschall <[hidden email]> wrote:
What helps a lot in terms of performance is to install WriteBarrier. Is that still true as of GOODS 3.02 and higher? I've been developing against a compile on GCC 4.0.1 and haven't had a single crash, but that could just be sheer dumb luck. If you've had issues even with recent versions, I'll downgrade. --Benjamin _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Benjamin Pollack
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 <[hidden email]> 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 Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Benjamin Pollack
On 12/15/06, Benjamin Pollack <[hidden email]> wrote:
> On a purely random note, why > are all the GOODS database classes prefixed with KK? Shouldn't it be DB or > GO or something? Those are the initials of the GOODS author, Konstantin Knizhnik. It was a prefix I was pretty sure would be unique... Avi _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Benjamin Pollack
2006/12/15, Benjamin Pollack <[hidden email]>:
> On 12/15/06, Philippe Marschall <[hidden email]> wrote: > > What helps a lot in terms of performance is to install WriteBarrier. > > Compile the server with GCC 2. Not GCC 3 and not GCC 4. > > > > Is that still true as of GOODS 3.02 and higher? I've been developing against > a compile on GCC 4.0.1 and haven't had a single crash, but that could just > be sheer dumb luck. If you've had issues even with recent versions, I'll > downgrade. No, that was with a 2.98 version that didn't even compile against GCC 4. So lets hope things are better with the 3 versions. Philippe _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Martin Beck-3
On 12/15/06, Martin Beck <[hidden email]> wrote:
Am Freitag 15 Dezember 2006 17:53 schrieb Benjamin Pollack: I don't know the reason, but I've had the same problem. Two years ago in college I was trying to write a Gmail-style web-based email client, using GOODS for the back-end. Part of the problem was that I wanted full-text search, which requires adding tens of thousands of objects to a collection in one commit on certain occasions. At the time, I eventually hit upon committing the changes in batches as a compromise between long commits and network latency. After some tuning, I think I managed to speed things up about five times or so that way. --Benjamin _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Martin Beck-3
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 _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |