BIND and write locks

I am trying to figure out, how write locks should behave WRT binding.

Take the following scenario:
- a collection C11
- a collection C1 containing a binding "foo" to C11 and mapped to URI "u1"
- a resource R2
- a collection C2 containing a binding "b" to R2 and mapped to URI "u2"

  foo|    |u2
    C11   C2

Now the following requests are issued (' marks locked resources):
- LOCK /u1 (write, exclusive, depth=infinity)
  --> C11 is automatically added to the write-lock
- PUT /u1/foo/a (passing locktoken)
  --> creates R1 which is added to the write-lock (RFC2518, Section 7.5)
- BIND /u1/foo (b->/u2/b, passing locktoken)
  --> R2 is added to the write-lock (RFC2518, Section 7.5)

  foo|    |u2
    C11'  C2
    a| b\ |b
     R1'  R2'

- REBIND /u2 (a->/u1/foo/a, passing locktoken)
  --> R1 is removed from the write-lock (RFC2518, Section 7.7)

  foo|    |u2
    C11'  C2
       b\ |b \a
          R2' R1

The described behavior for BIND and REBIND is what I suppose it should be.
Is it correct?

BTW, what happens if, afterwards, the following UNLOCK on R2 is issued:
- UNLOCK /u1/foo/b (passing locktoken)
  --> a) request is rejected, UNLOCK must be issued of C1 (/u1)
  --> b) all associated resources (C1, C11, R2) are unlocked (RFC2518,
Section 8.10.4)

I suppose, that it is not possible to remove single resources from the
write-lock by means of UNLOCK, isn't it?


At I found a link to, which
contains the following entry:

   "ID: 41
   Source: Reuter/Hunt
   Description: Specify how BIND interacts with a write lock.
   Status: Closed
   Resolution: Declined
   Locking semantics is in too confused a state currently to
   be able to make any reliable statements. Don't want to hold
   up binding spec till lock settles down."

Is that still prevailing?

Received on Monday, 1 September 2003 06:55:24 UTC