On 12/15/06, <b class="gmail_sendername">Ramon Leon</b> &lt;<a href="mailto:ramon.leon@allresnet.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ramon.leon@allresnet.com</a>&gt; wrote:<div><span class="gmail_quote">
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt; Hey, do you have any experiences with Seaside, GOODS and<br>&gt; heavy traffic on the server?<br>&gt; I hold a GOODS connection for every session and close it,<br>&gt; when the session is closed. However, it seems, that GOODS has
<br>&gt; problems with concurrency. For example:<br>&gt;<br>&gt; Client 1: read,&nbsp;&nbsp;&nbsp;&nbsp; , change,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; , commit<br>&gt; Client 2:&nbsp;&nbsp;&nbsp;&nbsp; , read,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; , change,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; , commit<br>&gt;<br>&gt; This gives a KKCommitFailure at the second commit (i think).
<br>&gt; Especially with BTrees and TSTrees this can be a huge<br>&gt; problem. How do other object oriented database solve this<br>&gt; locking and transaction things?<br>&gt;<br>&gt; Regards,<br>&gt; Martin<br><br>Isn't this exactly the expected behavior?&nbsp;&nbsp;This is standard optimistic
<br>locking, first commit wins, so where's the issue?</blockquote><div><br>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):
<br><br>Session 1: db root at: 'baz' put: 'frob'.<br>Session 2: db root at: 'bar' put: 'cow'.<br>Session 1: db commit.<br>Session 2. db commit -&gt; KKCommitFailure<br><br>You've got two solutions:<br><ol><li>Lock the object before you make the change. This can be done with KKDatabase&gt;&gt;writeLock: and KKDatabase&gt;&gt;readLock: and friends. This is the wrong solution for nearly everything, but it's nice to know it's there when you need it.
<br></li><li>Put your change to the tree inside a KKDatabase&gt;&gt;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.
</li></ol>On a purely random note, why are all the GOODS database classes prefixed with KK? Shouldn't it be DB or GO or something?<br><br>--Benjamin<br></div></div>