Branko Čibej <brane@xbc.nu> writes:
> I think *the* major task for 0.19 is:
>
> * Create a DB monitor that can detect crashed sessions and
> automagically unwedge the DB.
> * Stop creating transactions for read-only requests, and use
> ordinary locks instead.
> * Reduce the number of txn_checkpoint calls in our code, or even
> eliminate them completely.
All of these sound like good ideas (though I have some questions about
the second one), but aren't they independent? We can reduce the
frequency of txn_checkpoint calls without reducing the frequency with
which we create transactions in the first place, and vice versa.
Oh, I think I see: We can't switch to a locking system without a DB
monitor to detect a deadlocked database and break the cycles? (Or am
I just missing the point?)
In any case, the only 0.19 issue affected by these proposals would be
#995, "Large imports and checkouts over DAV can timeout". In any
case, 0.19 will not be the last milestone concentrating on scalability
issues, you can be sure :-).
> Before amyone starts wondering if I'm off my rocker,
I'm on the same rocker you are. However, a few questions:
Could you expand a little on point number 2? I'm not sure exactly how
you're proposing to use locks, and how they're supposed to replace
some of the functionality we get from transactions. For example, in
Subversion, read-only requests are usually reading from committed
revisions. So let's say we don't create a BDB transaction. How would
locking work?
'revisions':
Well, only the revprops might be changing. I guess one wants a
consistent picture of those. So we'd lock just the revision
record we're reading from, for the duration of the read. During
that time, someone changing a revprop on that revision would be
blocked, but that wouldn't be very long, so it's okay.
'nodes', 'representations', 'strings':
What do we lock here? Would the locking interfere with
deltification?
'changes':
No need to lock this for read-only operations, right?
I'm sort of thinking out loud here, but I get the feeling you have a
much more specific plan in mind...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 20 21:03:28 2003