Subject: RE: LOCK NULL reserves what?

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Thu, 19 Aug 1999 14:28:32 -0700

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.

			Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, August 19, 1999 11:14 AM
> To: [email-masked]
> Subject: LOCK NULL reserves what?
> 
> 
> 
> Whoops, I sent this to the wrong address last night....
> 
> My comments in my previous note remind me of something else.
> 
> If I have
> a lock-null resource, and if someone places a lock on the
> parent collection, am I blocked from doing a BIND or MOVE on my
> lock-null URI?  I believe the intent of the lock-null is to insure
> that we can do operations like  PUT/MKCOL there... but I'd think
> that BIND and MOVE also apply... at least in intent... but that
> seems to conflict with what we've been saying about BIND/MOVE
> being an operation on the state of the parent collection...
> and thereby blocked if someone else locks the parent.
> Any thoughts?
> 
> Yaron?  :-)
> 
> 
> ------------------------------------------
> Phone: 914-784-7569,   [email-masked]
>

---

From: [email-masked]
Date: Thu, 19 Aug 1999 17:55:49 -0400

The intent is that a lock on the parent collection preserves that namespace by
preventing the addition or removal of members. So any method that effects a
DELETE would fail as it changes the namespace even though it might be temporary.
The owner of the lock on the parent collection can change the collection
members, and the owner of the lock on the lock-null resource can set the
resource contents with PUT. But the owner of the lock-null resource cannot
UNLOCK or DELETE the lock-null resource, or MOVE it to a different parent.

[email-masked] on 08/19/99 02:14:09 PM

To:   [email-masked]
cc:

If I have

Yaron?  :-)

---

From: [email-masked]
Date: Thu, 19 Aug 1999 19:47:24 -0400

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. :-)