W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1998

Re: "Lost Updates" still persist

From: Judith Slein <slein@wrc.xerox.com>
Date: Mon, 23 Feb 1998 13:10:51 PST
Message-Id: <>
To: "S. Barr" <sbarr@interwoven.com>
Cc: "Yaron Goland" <yarong@microsoft.com>, "'Judith Slein'" <slein@wrc.xerox.com>, <w3c-dist-auth@w3.org>
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
>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.


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 16:05:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:17 UTC