Branko Čibej <firstname.lastname@example.org> 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
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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Feb 21 17:57:37 2003