- From: <ccjason@us.ibm.com>
- Date: Thu, 19 Aug 1999 19:47:24 -0400
- To: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>
- cc: w3c-dist-auth@w3.org
>> 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 Thursday, 19 August 1999 19:48:59 UTC