=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu> writes:
> D.J. Heap wrote:
>
> > It looks like when a deadlock occurs and subversion retries, there is
> > no randomized wait or anything (ala ethernet) before retrying...in
> > some cases I can see two processes deadlocking and getting aborted
> > over 20 or 30 times in a row before one finally makes it through, and
> > then the loser deadlocks with a third process multiple times. This is
> > just running 3 copies of stress.pl (which probably artificially
> > inflates deadlocks due to the small repo size?), but it is causing
> > heavy deadlock retrying on nearly every transaction.
> >
> > Probably not a big issue, but it could affect performance of numerous
> > users, I would think...perhaps some sort of ethernet style random wait
> > could help?
>
> Yes, I was thinking of this when I looked at the trail.c code the other
> day. I don't know if it really has to be randomized, though; a simple
> yield -- sleep(0) -- might be enough, given different timing.
Is this what you're looking for?
* subversion/libsvn_fs/trail.c
(svn_fs__retry_txn): Yield control on deadlock.
Index: subversion/libsvn_fs/trail.c
===================================================================
--- subversion/libsvn_fs/trail.c (revision 6063)
+++ subversion/libsvn_fs/trail.c (working copy)
@@ -150,6 +150,10 @@
/* We deadlocked. Abort the transaction, and try again. */
SVN_ERR (abort_trail (trail, fs));
+
+ /* Yield; let's see if some of the traffic congestion clears up
+ before we try again. */
+ apr_sleep (0);
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 27 17:30:33 2003