Re: Locking URIs rather than Resources

  Let's say that I have a "book" entity that I want to manifest as a
collection
  resource (with some additional XML properties describing the book's
state).
  In the collection is a set of HTML resources corresponding to each
chapter of
  a book.  Let's say that this book is a programmer's guide  for a software
  product, and a couple of these chapters are about "Getting Started".  Now
we
  add an administration manual (another collection somewhere else) and I
want to
  share the Getting Started (GS) info between books, so I want to move
those
  chapters into a third collection containing shared resources between the
  manuals.  I have the following collections now:

  /manuals/prguide
  /manuals/common
  /manuals/admin

  When I started working on the programmer's guide (PG), I depth:infinity
lock
  the entire collection with a shared lock, to make sure nobody messes with
the
  chapters while I am working.  When I move the GS info out of the locked
  collection I want to retain these locks, since they are still part of the
  manual.

  The automatic assumptions Jason proposes regarding when locks are removed
in
  the face of BINDs, MOVEs, etc. are not going to be correct in all cases.
If
  I depth lock a collection, I have a perfectly valid example of when I
want to
  retain the lock when members of a collection are moved out.  There is no
  recourse in this situation, since reestablishing the lock introduces a
race
  condition.

Of course it sounds like you don't need to (or want to) move it out of the
locked
collection though.  You just need to add a binding from the common
collection.  You get the right result that way.  Even for
exclusive locks.


  * when I refer to DELETEing a resource in my proposal earlier, I mean a
DELETE
  that removes the last binding, deleting the associated resource.

And if it is the last binding, whether the resource is locked or not is
probably moot.
If it isn't the last binding, then I take it you feel the resource remains
locked?

Received on Saturday, 8 January 2000 21:34:06 UTC