[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Transcript of chat between me and Sleeepycat

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-02-21 06:31:48 CET

Greg Hudson wrote:

>On Thu, 2003-02-20 at 16:39, Branko Čibej wrote:
>
>
>>>The more complex question is whether we need to be creating BDB
>>>transactions as often as we do, or whether we can get away with
>>>locking -- or nothing at all -- under some circumstances.
>>>
>>>
>
>
>
>>Yup. Except that "nothing at all" is likely to cause quite a few
>>headaches. :-)
>>
>>
>
>Really? It seems like we should only have to lock around the final step
>of a commit (the auto-merge), and everything else (report operations,
>most of a commit) can operate unlocked.
>
>
Greg! I expected better of you. :-)

Subversion txns do operate on logically separate node trees, but you're
forgetting that they use the same database tables as the other
operations. In the absence of "svn obliterate", you /can/ read from some
of our tables without locking the row (the nodes table comes to mind),
but the representations table isn't one of them -- representations can
change due to deltification, so you have to lock the rep when you read
it. You always have to create new rows in a transaction, too, at least
in the tables that use the "next-id" mechanism.

Also, there's no rule that says you have to create all of a commit txn
from a single-threaded client using a commit editor, or indeed from a
single client. You could easily have two processes building the commit
txn at the same time.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 21 06:32:27 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.