Re: Locking URIs rather than Resources

   From: ccjason@us.ibm.com

   <ja/> Now some locking questions. If LOCK applies to the name, not the
   resource, /x/y.htm is locked, and /b/c.htm is bound to the same
   resource as /x/y.htm, is /b/c.htm locked too? Probably not.

   <gmc/> Correct.  But modifying the resource identified by /b/c.htm
   does require the lock token for the /x/y.htm lock.  This does not make
   /b/c.htm locked.

   <jc/> Geoff, you agreed that "/b/c.html" is not locked.  In this case I
   think we'd preferably say the "the resource at" either/both URI's is
   locked... but only one of those URI's is locked.  My point is that we
   should probably come up clearer vocabulary/notation for making a
   distinction between the URI and the resource.  For example, we used to
   say the URI was protected and/or the resource was locked.

I agree.  If we say that a URL is locked, then we need a term to
describe a resource that is identified by a locked URL.  Let's try
just using the word "protect".  So a locked URL "protects" the
resource that it identifies.  If it does not (at a particular moment)
identify a resource, it does not (at that moment) protect any resource
(i.e. there is no "lock null resource").

So in the example above, we would say that the resource identified by
/b/c.html is protected by the lock on /x/y.htm.

   <ja/> What about LOCK  /b/c.htm?

   <gmc/> That is fine.

   <jc/> Hmmm.  Jim said they are the same resource.  I don't think he meant a
   null-mapped resource.  That being the case, I think you mean to say
   that the second lock can only be placed if it doesn't conflict with
   the lock already acting on the resource at that URI.  I think you must
   have assumed he meant a shared lock when you said that is fine.

Actually not.  I was using the "exclusive" aspect of a lock to be
completely URL based.  So you couldn't have two exclusive locks on the
same URL (i.e. you can't have a depth:infinity exclusive lock on /x
and an exclusive lock on /x/y), but you *could* have a resource that
is protected by two exclusive locks.

Although this simplifies LOCK/UNLOCK implementation for a server, I 
(believe I) agree that a client would rather the "exclusive" aspect
of a lock apply to the resource.  So a particular resource can only
be protected by one exclusive lock of a given type.  This modifies
the last line of the latest locking proposal, which would now state:

"A lock can be placed on a URL with a LOCK request.  This URL is called
 the "lock base".  If the lock is Depth:N, then a lock is induced on
 any URL that consists of the lock base extended by N or fewer
 segments.  Only an authorized holder of a lock token for a locked URL
 can modify either the state of the resource identified by the URL, or
 which resource is identified by the URL.  If a locked URL identifies a
 resource, the lock "protects" that resource.  A resource may not be
 protected by two exclusive locks with the same locktype."

This would then change my answer to Jim's question.  The revised
definition would not allow an exclusive write lock on /x/y.htm and
one on /b/c.htm, since that would result in a resource being protected
by two exclusive locks of the same type.

   <gmc/>  One user has /x/y.htm locked.  The other user has /b/c.htm
   locked.  That means you can't modify that resource unless you have both
   lock tokens.  In this model, a LOCK prevents a certain kind of change
   to something, but does *not* guarantee the ability to make such a change,
   since other access rights or locks can come into play.

   <jc/> I agree with what you said about not guarantee'ing a right to change,
   but what about requiring two tokens?  As far as I know, the situation
   you outlined can only happen if shared locks are used.  In that case,
   only one lock token is required.

Yes, for the situation where two URL's identify the same resource.
But there still will be operations that will require the use of
multiple lock tokens.  An example would be the original scenario
described by Yaron, where:

- /x identifies a collection
- /x/y does not identify a resource
- there is a depth:0 exclusive write lock on /x
- there is an exclusive write lock on /x/y

In order to do a "PUT /x/y", you would need a Lock-Token for both
the /x lock and the /x/y lock, since you are modifying the state of
both /x and /x/y.

Cheers,
Geoff

Received on Saturday, 1 January 2000 11:15:32 UTC