blair_at_apache.org writes:
> Author: blair
> Date: Thu Jan 27 06:31:21 2011
> New Revision: 1064003
>
> URL: http://svn.apache.org/viewvc?rev=1064003&view=rev
> Log:
> * STATUS:
> Nominate the 1.6.x-fsfs-begin-txn-deadlock branch.
>
> Modified:
> subversion/branches/1.6.x/STATUS
>
> Modified: subversion/branches/1.6.x/STATUS
> URL: http://svn.apache.org/viewvc/subversion/branches/1.6.x/STATUS?rev=1064003&r1=1064002&r2=1064003&view=diff
> ==============================================================================
> --- subversion/branches/1.6.x/STATUS (original)
> +++ subversion/branches/1.6.x/STATUS Thu Jan 27 06:31:21 2011
> @@ -247,6 +247,17 @@ Candidate changes:
> Votes:
> +1: pburba
>
> + * 1.6.x-fsfs-begin-txn-deadlock
> + Fix a deadlock that can occur when two or more multithreaded
> + Subversion servers on the same system serve two or more fsfs
> + repositories.
It didn't really deadlock did it? That would imply that some part of
the system locked up and stopped. What happened is the system detected
the deadlock, aborted the commit and continued.
You haven't really "fixed" it either as that would imply that the
deadlock can no longer occur, but it is still possible that that all the
retries fail. I accept that in practice the retry loop will work.
> + Justification:
> + Avoiding deadlocks is a good thing.
It's neater certainly, but why does it need to be fixed on the branch?
Why is having the client retry the commit not good enough?
> + Branch:
> + ^/subversion/branches/1.6.x-fsfs-begin-txn-deadlock
> + Votes:
> + +1: blair
> +
--
Philip
Received on 2011-01-27 10:53:32 CET