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

Re: [PATCH] Allow transparent slaves to handle REPORT?

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2007-10-12 23:51:47 CEST

On Oct 12, 2007 2:43 PM, Jack Repenning <jrepenning@collab.net> wrote:
> I originally thought, and you seemed to confirm, that users following
> the proper user-level protocol (lock-before-change) could sometimes
> end up making concurrent changes. That would be bad.
> But I now realize that lock-before-change is still safe, so I'm much
> less concerned.

Right. =)

> It occurs to me that the lock-that-gets-blocked now has two failure
> modes:
> (1) your local replica already knows someone else has the lock
> (2) your local replica is momentarily clueless, but by the time the
> lock request gets to the master it gets refused because you fell
> through the timing window
> If indeed there's potential for two different failure modes from what
> to the user level is the same problem, then I was sort of implying
> that they should result in the same error message.

The replica doesn't even try to handle the LOCK or UNLOCK methods - it
only attempts to serve the 'getlocks' discovery report. So, for case
(1), what the replica knows or doesn't know isn't helpful when a LOCK
or UNLOCK method comes across. So, I think these two modes are
indistinguishable from each other as the LOCK failure would only
happen at the master - not the replica. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 12 23:51:57 2007

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.