Re: DELETE leaving a lock-null resource; was LOCK Scenarios

<JC>
3) 8.10.5 says a DELETE destroys a lock at the destination.
I think this is not optimal.  A scenario is...  /a/b  exists
and is a resource... not a collection.  We want to replace it
with a new resource that is a collection.  But the spec says
that MKCOL can not replace am existing resource (or
collection).  It requires that a delete be performed first.
Now if one wants to accomplish this atomically (with
LOCKS), right now one has several choices.
      a) LOCK /a/.  It would probably be a depth 0 lock since
  there would be no point in locking at depth except possibly
  to prevent someone from tossing in another lock immediately
  after in the /a/b/... tree.    But if they did chose to use
  a depth lock, they'd also risk being unable to get the lock
  if someone for example has a conflicting lock somehwere in
  a /a/c/ tree.  It's a trade off. Depth or not, the other
  disadvantage of it is that they are also locking out any
  operations on /a/.  The point is that if they decide to lock
  /a/, they are locking more than they need to and may
  interfere with other principles... or be blocked themselves.
      b) LOCK /a/b.  But unfortunately with the current spec,
  the initial DELETE will destroy the lock.  So this isn't
  really a choice unless we want to reissue the lock... to
  create a null lock which is better, but still risks problems
  if another entity beats us to the punch.  It's a race condition.

Now if we altered 8.10.5 to allow support for not deleting the
lock, we could act surgically to insure that we get exactly the
safe atomic behavior we want.  (Ignoring a tangential caveat.)
We lock /a/b possibly at depth.  Do the delete specifying that
we want the lock retained.  Then do the MKCOL /a/b/ and any
other operations we require.  When done, release the lock. Once
again ignoring an unspecified caveat, we know that as soon as
we get the lock that we're going to be able to acomplish what
we set out to do without another principle interfering.

If we don't want this, then I think we need to evaluate why we
support lock-null resources.  I'd think the arguments for each
of these are the same.
</JC>
<jra>
There are a large number of situations in authoring environments where
transaction semantics are required. WebDAV doesn't (yet) support transactions,
and I don't think we should attempt to come up with a lot of special cases (like
lock-null resources) supported by the protocol to overcome this important
missing function. Rather let's propose an extension that does support
transactions. Might be pretty hard with a stateless server though.
</jra>
<JC>
So you're not a fan of lock-null resources either at this stage.  That seems
consistent.

JimA and I have been doing all the talking for the last day.  Anyone else want
to be heard?  :-)
</JC>

Received on Wednesday, 18 August 1999 14:46:20 UTC