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.
Yup.
> >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
thought.)
> 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.
Gotcha.
> 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?
-K
---------------------------------------------------------------------
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