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

Re: When to use Berkeley transactions.

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2003-02-21 17:23:48 CET

Branko Čibej <brane@xbc.nu> writes:
> No it's not. A transaction is _not_ invisible to other users of the
> database, even when not committed. Nobody outside the transaction sees
> the changes until they're committed, but everybody sees the locks that
> the transaction creates -- and the transaction sees other people's locks.

Uh, right. Since I said the same thing about the locks in my original
post, I assumed it was obvious what "invisible" meant in this context
:-). I could describe it more elaborately if needed; perhaps "opaque"
would have been a better word.

> [skip lots of txn-101 that Karl just invented]

Brane, wouldn't you rather be specific than rude, dear? :-)

> >Of course, we could do it without transactions, if we implemented our
> >own locking scheme. And that locking scheme would be equivalent in
> >power and scope to... Berkeley transactions!
> There's another locking scheme, and it's called Berkeley locks. You can
> lock and unlock an object (a table row, if you will) without starting a
> transaction (and all the logging that involves). It's just that locking
> happens automatically when you touch an object from within a transaction.


> >and it would come at a high cost in complexity and new bugs.
> Our code wouldn't become that much more complex.

That's great! (Surprising to me, but it's clear you've given it more

> The nice thing about this, implementation-wise, is that we can make a
> /gradual/ move from reads-with-txns to reads-with-locks. Do the easy
> ones first ('revisions', 'nodes', 'representations'), then move on to
> the hard ones.


> P.S.: All of the above assumes that we don't have "svn obliterate". Once
> we have that operations, we'll definitely have to lock 'nodes' and
> 'changes'.

Sure, we can cross that bridge when we come to it.

So the question is, what's the best course of action? Is there an
initial small-change-with-big-effect that you think would be best to
start with first?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 21 17:57:37 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.