RE: LOCK NULL reserves what?

To quote from section 7.5:

   A write lock on a collection, whether created by a "Depth: 0" or
   "Depth: infinity" lock request, prevents the addition or removal of
   member URIs of the collection by non-lock owners.  

Hence if a/b is WRITE locked then a singleton WRITE lock on a/ will fail
because the WRITE lock on a/b, as specified in section 7.1, reserves the
write for DELETE.

In other words:

1. a/b is WRITE locked and thus has exclusive use of DELETE
2. The depth: 0 WRITE lock on a/ reserves the write to DELETE on a/ and its
immediate children.
3. Since a/b is WRITE locked the WRITE lock depth:0 request on a/ MUST fail.

			Yaron

> -----Original Message-----
> From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com]
> Sent: Thursday, August 19, 1999 4:47 PM
> To: Yaron Goland (Exchange)
> Cc: w3c-dist-auth@w3.org
> Subject: RE: LOCK NULL reserves what?
> 
> 
> 
> >>
> Step 1 - User A successfully take out an exclusive write lock 
> on a/b, which
> is a lock null resource.
> Step 2 - User B tries to take out an exclusive write lock, 
> depth = infinity
> on a/. The write lock will fail because a/b is already locked.
> >>
> 
> Perhaps I should have been clearer.  What if step two is a 
> singleton, not a
> depth lock request.  Can User A do a BIND/MOVE/and other operations
> that we usually think of as modifying the state of /a/?
> 
> I'm asking for the original design philosophy and the what 
> we'd actually
> like to see now.  Two questions.
> 
> It does beg a second question.  Reverse the order of the 
> steps.  Can the
> lock null resource be created if the parent is locked?   I 
> think the answer
> to this is easier. :-)
> 
> 
> 
> 
> 
>

Received on Tuesday, 21 September 1999 15:07:42 UTC