RE: Locking containers

This should be solved by forcing the lock on the collection to lock all sub-resources. If this is not the case then what is the point of a lock on a collection?

Cheers
Dylan

----------
From:  Jim Whitehead[SMTP:ejw@ics.uci.edu]
Sent:  Mittwoch, 11. Juni 1997 16:08
To:  w3c-dist-auth@w3.org
Subject:  Locking containers

One issue still remaining in the current locking draft (available at
<http://www.ics.uci.edu/~ejw/authoring/proposals/locking.html>) is how to
handle an exclusive write lock on a container.

At present, an exclusive write lock on a container prevents modification of
the membership of the container by any principal other than the owner of
the lock, i.e., preventing the addition and removal of members of the
collection. So far, so good.

However, an exclusive write lock on a member of a collection is currently
defined such that the owner of the lock may delete the resource.

The dilemma occurs during the following scenario: Principal P1 takes out an
exclusive write lock on Resource B which is a member of collection A.
Principal P2 later takes out an exclusive write lock on collection A.  What
does each lock mean in this situation?  If P2 can delete B, what then is
the meaning of the lock on A?  It appears that in this case, the meaning of
the lock depends on the state of locks on other resources, which is not
desirable.

This raises some questions.

1) Is it useful to allow locking of containers at all?

2) Assuming it is useful (I suspect there are many cases where this
functionality is needed), which of the several ways of solving this is
best?

One way is to mandate that an exclusive write lock on a container must lock
all members and subcollections -- if there are any existing locks on any
members, or members of subcollections, then the lock request fails.  Thus
there is no problem with locks changing meaning, because a lock of a
container also locks its members.  However, performing a recursive lock
like this is expensive, especially if you only want to make changes at one
level of a multi-level hierarchy.

Another way is to define an exclusive write lock such that the owner of the
lock is not guaranteed the ability to DELETE the resource (assuming they
have sufficient access rights to delete the resource).  To guarantee the
ability to delete the resource, they need to lock the collection containing
the resource.  This is less expensive than locking all levels of the
hierarchy, but does have the drawback that there is very little difference
between deleting a resource (which would not be allowed by a lock on an
individual resource) and zeroing out the contents of a resource (which is
allowed by an exclusive write lock on an individual resource).

- Jim

Received on Monday, 16 June 1997 05:53:41 UTC