W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1999

RE: LOCK NULL reserves what?

From: Yaron Goland (Exchange) <yarong@Exchange.Microsoft.com>
Date: Tue, 21 Sep 1999 12:07:25 -0700
Message-ID: <078292D50C98D2118D090008C7E9C6A603C96653@STAY.platinum.corp.microsoft.com>
To: "'ccjason@us.ibm.com'" <ccjason@us.ibm.com>, "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>
Cc: w3c-dist-auth@w3.org
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.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:20 UTC