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