[Prev][Next][Index][Thread]

RE: Lock timeouts revisited

We here at Microsoft must have locks without timeouts. This does not
mean that we should not implement locks with timeouts. Rather it means
there must be a way to specify "This lock has no timeout". As long as
that feature exists I am agnostic on the issue of timeouts.
					Thanks,
							Yaron

>-----Original Message-----
>From:	Ben Laurie [SMTP:ben@gonzo.ben.algroup.co.uk]
>Sent:	Saturday, September 28, 1996 3:19 AM
>To:	Jim Whitehead
>Cc:	w3c-dist-auth@w3.org
>Subject:	Re: Lock timeouts revisited
>
>Jim Whitehead wrote:
>> 
>> 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.
>
>Perhaps it would be worth considering a DHCP-style lock - where you establish
>a lock for a fixed period which can be renewed (without release)
>periodically.
>
>Cheers,
>
>Ben.
>
>> 
>> - Jim
>> 
>> 
>
>-- 
>Ben Laurie                  Phone: +44 (181) 994 6435
>Freelance Consultant and    Fax:   +44 (181) 994 6472
>Technical Director          Email: ben@algroup.co.uk
>A.L. Digital Ltd,           URL: http://www.algroup.co.uk
>London, England.            Apache Group member (http://www.apache.org)
>