Subject: RE: What is left after LOCK/UNLOCK on null resource?

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 5 Sep 2002 13:51:13 -0400

On at least one point, Dan and I are in complete agreement,
which is that I speak for myself, and not for the working group
as a whole.

But until Dan (or someone) has published a convincing rationale
for having multiple processes reuse the lock token for an exclusive
lock,  I will continue to maintain that an exclusive lock token should
only be used in an update request (PUT/PROPPATCH) by the process
that took out the lock originally.  (Note that I do not at all 
object to another process UNLOCK'ing a lock created by another
process).

If you want to allow multiple processes to effectively "share"
a lock token, the protocol has defined shared locks.

My point about using the DeltaV protocol for "long-lived locking"
(or "shared locking) applications was that using this protocol
would allow a client to effectively interoperate with a wider
variety of servers (both versioning and non-versioning), with the
"version URL" effectively replacing the functionality of the
"shared lock token". 

Cheers,
Geoff 

-----Original Message-----
From: Dan Brotsky [mailto:[email-masked]]
Sent: Thursday, September 05, 2002 12:20 PM
To: Michael Leditschke
Cc: [email-masked]
Subject: Re: What is left after LOCK/UNLOCK on null resource?

Michael,

Just for the record, I disagree with most all of Geoff's responses here 
(and in the subsequent thread), and I don't think he speaks "for the 
working group" in saying that the DAV spec favors time-limited locking.

In the first place, I think client implementation (at the level, for 
example, of "process") is way outside the scope of the spec.

Second, I believe that the language of the spec (as written) 
intentionally doesn't say much at all about what constitutes an 
"authoring client" (see section 6 on locking).  I think that's 
appropriate both because HTTP 1.1 is profoundly neutral about it and 
because WebDAV hopes to allow a broad range of interoperable 
implementations.

Third, there is a broad class of existing, interoperable 
implementations (the Adobe Systems WebDAV-enabled products) which 
communicate tokens among processes, persist tokens between invocations 
of processes, and use LOCKDISCOVERY values (both tokens and owner 
props) as a means of interoperating on the client side about authoring 
responsibility.  These impementations work against servers which allow 
infinite-duration locks and those which don't.

FWIW, I believe that lock expiration is really tied to a usage model in 
which clients actually use the server as a "remote file system," in the 
sense that they may only have a non-persistent buffer locally and all 
saves are done directly back to the server.  This is the model that 
Microsoft office clients use, for example, and they use lock timeouts 
as a way of preventing lock stranding when clients crash.

The model you outlined---a local working copy is made of a locked 
resource, that local copy is edited over an indefinite period of time, 
that local copy is occasionally "published" to the server, and then the 
server resource is unlocked after all local editing is complete---is 
exactly the model used by Adobe clients.  (I have been meaning for some 
time to write an explanation of why Adobe uses this model; maybe this 
thread will finally get me to do that.  Then again, maybe not. :^)  
But, in any event, it is quite natural in this model for lock tokens to 
be persisted by the editing clients that are using the local copy, 
because in this model all the editing state (including the lock token 
and owner information) is local-disk-specific not process-specific.

Finally, I'm not really sure why Geoff says that delta-V is 
specifically better suited than "plain" DAV for use by clients who use 
long-term locks.  Versioning servers are arguably a better choice than 
non-versioning servers for almost all collaborative authoring 
applications, delta-V is (of course) a DAV extension, and in fact 
delta-V specifically provides for backward compatibility around DAV 
locking for non-delta-V clients who wish to get the benefits of 
versioning.  So I really don't think lock (or checkout) duration has 
much to do with the difference between delta-V and DAV.

     dan

On Wednesday, September 4, 2002, at 07:28 PM, Clemm, Geoff wrote:

>
>    From: Michael Leditschke [mailto:[email-masked]]
>
>    DAV locks are
>    supposed to be capable of being held for an extended time.
>
> Only by the process that took out the lock.
>
>    I might
>    want to lock a resource, edit it for a while locally, then push the
>    result back and unlock it again. Are you suggesting this all has
>    to be done by the same OS process?
>
> Yes.
>
>    What happens if the power goes out and my PC reboots?
>
> The new process needs to obtain its own (new) lock.  The old
> lock is cleaned up by a timeout, or if allowed by the server,
> the new process can clean up the old lock with an UNLOCK.
> The new process shouldn't "reuse" the old lock, unless you have
> some way of guaranteeing that two processes cannot both reuse the
> old lock at the same time.
>
>    Or perhaps you expect the client to cache locktokens?
>
> Only if the cache has some way of guaranteeing that only one
> process can obtain the cached locktoken.
>
>    In my case, it is the same client I'm using to lock and unlock and
>    I'm presenting the same credentials to the server. Its a low
>    level test program, so I would have thought being able to unlock
>    a resource of which I am the owner would be reasonable.
>
> Unlocking is reasonable (unlike "reusing", which is not), but some
> servers do not trust clients to appropriately unlock something they
> didn't lock (since the client can't automatically know that it is
> appropriate to do so, and even if it asks the user, the user can be
> mistaken).  Those servers require clients to depend on timeouts.
>
> Cheers,
> Geoff
>

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 5 Sep 2002 15:43:37 -0700

> object to another process UNLOCK'ing a lock created by another

If you're editing a document, and your machine crashes, you would like to
reboot your machine, and then restart your authoring application to continue
editing the same document. This is strictly a different operating system
process than the one that took out the lock, yet this new process should be
able to assume the existing lock.

Alternatives, such as the Office model where locks last for only two
minutes, allow the lock to timeout while the machine is being rebooted, and
hence it's possible for the lock to be grabbed by another person after it
has expired. Social conventions surrounding turn-taking in collaborative
authoring tend to make it so this doesn't actually happen, but the
possibility does exist.

It is also possible to require the new editor instance to explicitly remove
the existing lock, then take out a new one, but to do this requires the same
information you'd need to assume the existing lock, and still provides a
small window of lock-grabbing vulnerability.

> a lock token, the protocol has defined shared locks.

Shared locks don't strike me as being appropriate for this case, since you'd
have two shared locks, each owned by the same person (DAV doesn't have a way
to explicitly represent the process taking out a lock).

- Jim

---

From: Dan Brotsky <[email-masked]>
Date: Thu, 5 Sep 2002 16:17:12 -0700

On Thursday, September 5, 2002, at 10:51 AM, Clemm, Geoff wrote:
> ... until Dan (or someone) has published a convincing rationale

Ah!  Thanks for adding this last piece of your position, Geoff, it 
really brought something into focus that had eluded me about your 
argument.  I will attempt (in a message under a different subject line) 
to provide the "convincing rationale" you are asking for :^).

> "version URL" effectively replacing the functionality of the

I think we agree on this, too.  I just wouldn't call this "long-lived 
locking."

     dan