On Tue, May 20, 2003 at 04:32:58PM +0200, brane@xbc.nu wrote:
> Quoting "Glenn A. Thompson" <gthompson@cdr.net>:
>
> > Hey,
> >
> > >Yes. The granularity of our transactions is far, far too large, and we
> > >have absolutely no control over locking order. I'm 99% certain that's
> > >where the deadlock comes from -- we simply don't access the various BDB
> > >tables in a well-known order, and we keep stuff locked longer than
> > >necessary.
> > >
> > >
> > Are there any methods in particular that rise to the top of a potential
> > hit list?
>
> Once upon a time I started analysing that code, and failed miserably. :-( Trails
> start so high up in the API that it's practically impossible to refactor things
> without turning the API upside down. Which, I understand, is what _you_'re
> doing. So there's hope after all. :-)
A long while back, I came up with an idea that I think might help this out
quite a bit. I suggested the notion of an "operation count" that is stored
in each trail object. Every time we hit BDB, we do that within the context
of a trail. If we simply increment an opcount for each operation, and then
discover that certain things would create an opcount of 5000, then we know
we've got some investigation.
The fewer BDB operations per trail, then the smaller the locks. Generally.
It is at least a start to find the problematic areas.
Does that seem reasonable? Or am I missing something, and this wouldn't
actually help much?
There's an issue opened on this, but I think it might be marked as post-1.0.
Of course, that simply means "we'll do it later, but if somebody is
motivated, then supply a patch and we'll do it now".
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 21 03:27:42 2003