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

Re: svn commit: r1064003 - /subversion/branches/1.6.x/STATUS

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 27 Jan 2011 09:52:48 +0000

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

This is an archived mail posted to the Subversion Dev mailing list.