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

On Thursday, September 5, 2002, at 10:51 AM, Clemm, Geoff wrote:
> ... 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.

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 :^).

> 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".

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

     dan

>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Dan Brotsky [mailto:dbrotsky@adobe.com]
> Sent: Thursday, September 05, 2002 12:20 PM
> To: Michael Leditschke
> Cc: w3c-dist-auth@w3.org
> 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:mike@ammd.com.au]
>>
>>    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
>>
>

Received on Thursday, 5 September 2002 20:39:38 UTC