Lock timeouts revisited

At the Cambridge meeting the issue of lock timeouts was discussed.  I was
in favor of having locks which automatically timed-out after a given
duration, and the remainder of the participants were either neutral, or
somewhat opposed to the idea.

I'd like to revisit this issue, because discussions I've had about locking
since have convinced me that lock timeouts are a good thing, and we should
include them in the functionality we propose.

The compelling reasons for having lock timeouts stem from a consideration
of what to do when someone has a lock out, and then forgets about it, and
someone else needs the locked capabiity on the resource. This is a fairly
common occurrence.

Today, most systems allow someone to become a super user and then manually
remove the lock.  Typically there are enough people around with super user
capability that removal of locks isn't a big problem.  This practice does
depend on having access to the people with lock removal priviledges.

In a distributed authoring situation, it is likely that lock breaking
capability will be limited to a very few people.  For example, in the case
of an Internet Service Provider maintaining a web space for hundreds of
people, it is likely there will only be very few employees of the ISP with
lock breaking capability, and they will not want to be bothered with this
activity.

Thus there is a need for a way to decentralize lock-breaking authority.

One solution to this problem is to have locks which time out, with an
adjustable timeout value.  Some locks could time out every day, every hour,
or even after a week.  This timeout value could be altered to meet the
needs of the local environment.

- Jim

Received on Friday, 27 September 1996 17:21:22 UTC