RE: Issue: Locking namespaces vs. resources

> -----Original Message-----
> From: Jason Crawford [mailto:ccjason@us.ibm.com]
> Sent: Thursday, May 24, 2001 9:26 PM
> To: Eric Sedlar
> Cc: WebDAV WG
> Subject: Re: Issue: Locking namespaces vs. resources
> <<
> There was a long discussion of locking a URL (so that a resource can't
> move when locked) in the fall of 1999, and in looking back through the
> archive, I didn't get a feeling of resolution that the spec should be
> changed in any way.
> >>
> We didn't resolve it, but we were close.  In Dec 99 the locking discussion
> got defered as some of the advanced collections issues were suddenly hotly
> debated.
>

That's why I brought it up.  I thought we could resolve this without too
much more debate.

> <<
> from Yaron, and there were a number of proposals to actually specify
> whether you wanted a namespace lock or a resource lock, rather than
> leaving this vague.  I still think this is very useful, for performance
> reasons
> >>
> I assume people tend to lock resources because they want to work on them
> and modify them.  I can't imagine one wanting to allow folks the resource
> they are working on unless... (1) moving it doesn't prevent them
> from being
> able to "check their modifications in".   Or (2) they know there is no one
> that will move it.  How common are these?  Are there other cases?
>

Geoff cited a number of cases where an administrative type of person might
want to move whole directory trees while a user is editing a file.  On UNIX,
this wouldn't be a problem, since the client would have an open file
descriptor, and the data would still get saved.  In WebDAV, the client would
have to process the 302 and use the new URL.

> <<
>  (I think Greg Stein mentioned that mod_dav must recursively
> search the source directory for locks before doing a MOVE for just this
> reason--not a good thing)
> >>
> I think there is an alternative algorithm that can be used whereby locking
> marks the bindings between the locked resource and the root resource
> of the namespace.  The cost of marking/unmarking should be O(log(n)) where
> n is
> the number of resources in the system.   The cost of checking before
> breaking
> a binding should be O(1).  In other words, not expensive if this algorithm
> can be used.   Is there a problem doing this?  It doesn't sound expensive.
> Is
> it?
>

O(log(n)) can still be expensive as n grows, and some people want a very
large n on their website.  It's not like it's horrible, though, either.
Keeping track of open locks that must be moved is much easier, however,
since my guess is that the number of open locks will be less than log(n)
on most systems.  So, allowing LOCKED files to move is still less of a
performance burden.

I don't care that much if we want to say that WebDAV locks must always
lock the part of the namespace needed by that URL, or if we provide
clients a choice (it's clear that we must provide a way to lock the
namespace, though).  I think we should just be clear in the spec as to
what locks do, though.

--Eric

Received on Friday, 25 May 2001 13:05:12 UTC