Re: resourcetype locknull

   From: John Stracke <francis@ecal.com>

   Consider what happens if you need to create a resource with a particular
   body and some particular properties.  If you don't have lock-nulls (or
   transactions), then you do PUT, LOCK, PROPPATCH, UNLOCK

Actually, since you don't know whether or not something is there
already, you'd always first try the LOCK.  If the LOCK fails (because
there is no resource there to LOCK), you do a PUT (with an empty body)
followed by a LOCK.

So what you do is:

LOCK (if fail because no resource there, then PUT null-body; LOCK)
PUT; PROPATCH; UNLOCK

So all LOCK-NULL buys you is the avoidance of the extra PUT/LOCK in
case there is no resource there yet.

   (or maybe skip the
   LOCK/UNLOCK, since it's only protecting one operation).

Even if you just did a single operation, you still want the
LOCK/UNLOCK to prevent another (locking) client from performing
its edits using the state of the resource prior to your
operation (i.e. you don't want to "lose" your operation).

   If you and
   somebody else are trying to create it at the same time, then you could get
   PUT1, PUT2, PROPPATCH2, PROPPATCH1, resulting in resource whose properties
   don't match its body.  With lock-null, you can do LOCK, PUT, PROPPATCH,
   UNLOCK.

Without lock null resources, you still wrap LOCK/UNLOCK around
your sequence of operations.  The only difference is that if your
LOCK fails because there is no resource to LOCK, you issue a PUT
with an empty body, followed by a retry of the LOCK.

Note: If someone gets in ahead of you and locks the dummy resource
you just created, that's no different than someone getting their
lock-null LOCK request in ahead of you.

Note 2: Hopefully there are some GET's and PROPFIND's mixed in
with those PUT's and PROPPATCH's, or else you're going to lose
the previous updates, whether or not you use LOCK's.

Cheers,
Geoff

Received on Wednesday, 13 October 1999 23:08:19 UTC