RE: "Lost Updates" still persist

You are correct, the "lock optional" model (discussed below) still suffers 
from lost updates, and my two letters this morning are cause for confusion. 
 Let me propose a taxonomy of WEBDAV locking models to help our discussion:

Here are the three main categories of locking models that the current 
WEBDAV draft supports:

lock always (no "lost updates"):
   - WEBDAV server requires that a resource is locked before 'PUT' (or any 
other modifier) can occur.
   - lock token must be presented for every PUT

lock optional (possible "lost updates" - dangerous unless all clients are 
well behaved):
   - WEBDAV server allows locks to be taken or not
   - lock token only needs to be presented for locked resources

lock never:
   - WEBDAV server fails all lock requests (proposed clarification)
   - lock tokens are never required.

"lock always" and "lock never" modes are safe, since clients can always 
guarantee their understanding of the state of a non-live resource.  And as 
I previously mentioned, "lock optional" is downright dangerous (and I doubt 
it will be implemented in anything but the most controlled environments).

(Up until today, I believed "lock always" was unachieveable with the 
current spec, hence my alarm at only being only left with the "lock 
optional" and "lock never" models.  This morning, in disbelief that the 
spec wouldn't enable a "lock always" design, I had the pleasure of 
discovering that 5.1 and 8.7 read as one would satisfy the requirement.)

My last two letters were focusing only on the "lock always" and "lock 
never" models.  And as you aptly point out, in the "lock optional" model, 
"lost updates" still exist and I still strongly agree that a special 
section noting the inherent dangers of this model are appropriate.  As I 
revisit it, please disregard my original edit for 4.3 since it ignores the 
"lock optional" mode.

With that in mind, since it's helped clarify my thinking, I'm wondering if 
we should integrate a locking taxonomy into the implementation note for 
4.3. to help clarify both the models and the guarantees?

Equally well, If it hasn't already been addressed in the 07 spec, an 
explicit note about failing lock requests for non-locking servers/ 
non-lockable resources might be beneficial.

-San


Sanford L. Barr wrote:
>If we require all servers to explicitly fail 'LOCK' requests on
>non-lock-enforcable resources, then 'B' will never be under a false
>assumption that it's preventing other clients from writing to the resource
>and can take appropriate action.
>
>I'd like to enlist help from the members of this list to flesh out the
>following proposal:
>
>Add text to either 7.12 or 8.7 that states something to the effect of: 
'LOCK
>requests on non-lock-enforcable resources MUST explicitly fail.  For 
servers
>that don't support locking, all LOCK requests MUST fail'.  (Either using
>'424 - Method Failure', or another code explicitly stating 'Method Not
>Supported').



-----Original Message-----
From:	Judith Slein [SMTP:slein@wrc.xerox.com]
Sent:	Monday, February 23, 1998 1:11 PM
To:	S. Barr
Cc:	Yaron Goland; 'Judith Slein'; w3c-dist-auth@w3.org
Subject:	Re: "Lost Updates" still persist

Now I'm really confused.  I thought you were correct in your earlier
analysis, that we could not prevent A from overwriting B's changes.

At 12:24 PM 2/23/98 PST, S. Barr wrote:
>It seems that "lost updates" are already prevented for servers that 
enforce
>locking on specified resources, and we may be able to prevent the scenario
>for non-locking servers (or non-lock-enforcable resources) without much
>work:
>
>From 8.7 and 5.1, locking servers can prevent the scenario from occuring
>altogether.  For these servers every PUT on a locked resource will have to
>be accompanied by a valid locktoken which the server can verify and 
enforce.
>In this case, Client A's 'PUT' would never succeed.

Every PUT on a locked resource does need a locktoken, but the resource is
no longer locked when A does its PUT, so the PUT succeeds.

>
>For non-locking servers (or the case where the lock on the resource in
>question is non-enforcable), the scenario between A & B can only exist if
>the server falsely claims that it's locking a resource.  (The WEBDAV 
server
>would have had to grant a non-enforcable "lock" to 'B').

It's true that a non-locking server should always fail a lock request.  But
in the scenario, the server did successfully execute B's lock.  The server
does enforce B's lock.  If A had tried to lock the resource while B held
the lock, A would have failed.  If A had tried to PUT the resource without
the appropriate locktoken while B held the lock, A's PUT would have failed.

--Judy

Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	(716) 422-5169
Fax:		(716) 422-2938

Xerox Corporation
Mail Stop 105-50C
800 Phillips Road
Webster, NY 14580

Received on Monday, 23 February 1998 19:13:46 UTC