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