Subject: One lock per resource per person?

From: [email-masked]
Date: Fri, 15 Oct 1999 15:13:59 -0400

In an offline discussion, the following question came up...

   Is it possible for a single principle to have multiple locks per resource?

I'd like to hear some opinions... but here are some mental exercises...

Lock tokens were invented to deal with the situation where the left hand and the
right hand don't know what each other is doing.   Otherwise it would be
sufficient to be authenticated as the entity that owns the lock.  It's important
to actually hold the lock to demonstrate awareness of it.  (It's also why we
supposedly also have to be careful how we use lockdiscovery.)

This philosophy suggests that there can only be a single exclusive lock on a
resource.  No exceptions.  If the left hand and right hand really know that they
won't step on each other... they can simply use the same lock token.   Even the
owner of the existing exclusive lock can't get another of the same type.  I
suppose the one possible exception would be if they submit the existing lock
token.  Buf for now I'll suggest that there can only be one exclusive lock per
resource.  Period.

This leaves the case of shared locks.   I think the answer here is different.
We don't exclude different people from holding the same lock.  Why should we
exclude the right hand and left hand?  Also in the case of...

   /a/b

I believe PersonX can already shared depth lock /a/ and still have another
shared lock on /a/b.  So I believe it's already possible for one principal to
have multiple locks per resource.

Comments?

Do we require a modification to 2518?

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: [email-masked] (WJCarpenter)
Date: Fri, 15 Oct 1999 13:08:08 -0700

ccjason> Lock tokens were invented to deal with the situation where
ccjason> the left hand and the right hand don't know what each other
ccjason> is doing.

Which reminds me of yet another locks-and-simplification issue....

RFC-2518 wants LOCK tokens to be universally unique.  Isn't it
actually sufficient that they be unique relative to the LOCKed
resource, kind of along the same lines as entity tags are unique?  

In fact, as an implementation choice (and imagining the spec didn't
explicitly prohibit it), if a server only supported exclusive write
LOCKs, couldn't a server choose to trust clients to do the right
thing, and use the string "button-button-you've-got-the-button"
for every LOCK token issued?
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

---

From: Jim Whitehead <[email-masked]>
Date: Sun, 17 Oct 1999 17:16:10 -0700

> resource, kind of along the same lines as entity tags are unique?

The strongest requirement for globally unique lock tokens comes from looking
at the future where there could be multiple WebDAV servers participating in
a cooperative cluster.  In that case, having globally unique lock tokens
would prevent lock token collisions.

My original rationale for uniqueness can be found in the archives at:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JanMar/0325.html

(I found this URL by going to Google http://www.google.com/ and searching on
"lock token uniqueness").

- Jim

---

From: [email-masked] (WJCarpenter)
Date: Mon, 18 Oct 1999 14:49:42 -0700

jw> The strongest requirement for globally unique lock tokens comes
jw> from looking at the future where there could be multiple WebDAV
jw> servers participating in a cooperative cluster.  In that case,
jw> having globally unique lock tokens would prevent lock token
jw> collisions.

Isn't this a quality-of-implementation issue?  If multiple servers
need to access the same physical repository, a privately-arranged
scheme can be used to keep them from colliding with each other
(possibly even some server acting as a clearinghouse for doling out
LOCK tokens).
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3