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

Re: svn.collab.net is now running Subversion 0.23.

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-05-20 17:42:04 CEST

William Uther wrote:

> On Tuesday, May 20, 2003, at 02:40 PM, cmpilato@collab.net wrote:
>> =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu> writes:
>>> Branko ÄŒibej wrote:
>>>> I now have stress.pl running on Windows
>>> svn: Berkeley DB deadlock error
>>> svn: Berkeley DB error while reading node revision for filesystem
>>> r://repostress/db:
>>> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
>>> svn st -u wcstress.3768: failed: 256
>> So, I'm remember how we print error messages, it looks like the
>> deadlock happens first, and *then* the "already exists" is tacked onto
>> it.
> [snip part about "already exists" being bogus]
>> Still, the deadlock concerns me.
> Deadlocks are to be expected, I think. You either:
> i) Avoid deadlock by using one big lock. This is inefficient.
> ii) Avoid deadlock by making sure you always acquire locks in the same
> order, and release them in reverse order. This might be possible if
> you made sure that paths were accessed in sorted order. I don't
> really know how this works with the subversion schema and BDB
> transactions though. I think the lazy copies make this impossible.

You could be right about that.

> iii) Don't avoid deadlock, but deal with it seamlessly. When you get
> a deadlock, one of the deadlocked transactions is aborted. You should
> be able to redo the command though, and I would have thought that svn
> should do this automatically. When restarted, the command should
> succeed (the other transaction in the deadlock should have
> completed). One detail is that when you restart a commit you may find
> you are no longer up to date and so abort for that reason.

We actually do have code in trail that retries a transaction in case of
a deadlock. I suspect the deadlock error code is being wrapped
somewhere, so this could be a simple coding bug. I can consistently
reproduce this error message on both Windows and Linux with BDB 4.0.14,
if I get three stress.pl instances running in parallel.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 20 17:42:47 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.