Jini Distributed Leasing Specification (was Re: timeout types)

----- Original Message -----
From: Jim Whitehead <ejw@ics.uci.edu>
To: WJCarpenter <bill@carpenter.org>; <w3c-dist-auth@w3.org>
Sent: Monday, January 24, 2000 10:57 AM
Subject: RE: timeout types


>
> Bill Carpenter writes:
> > RFC-2518, example in section 8.10.8, and description of
> > DAV:lockdiscovery in section 13.8 mention a "timeout type" for a
> > LOCK.  As far as I can tell, the example doesn't show any kind of
> > "timeout type" (particularly the one it says it shows), and I don't
> > see a description of "timeout type" elsewhere in RFC-2518.
> >
> > Perhaps the "timeout type" is a holdover from an earlier draft and
> > just needs an editorial cleansing?
>
> Well, "timeout type" is used slightly inconsistently within the spec.  In
> section 9.8, which defines the Timeout request header, there is a TimeType
> BNF production which describes the syntax of the # of seconds the lock
will
> last, in addition to having an "Other" production, which is intended to
> allow extensibility.  So this is one meaning for "timeout type" -- the
> TimeType within the Timeout request header.  It is this sense of "timeout
> type" that is used in section 13.8.

Are you familiar with the "Lease" technique which I first encountered in
Sun's specifications for Jini?

<http://www.sun.com/jini/specs/lease101.html>

Leases represent a very intuitive (IMO) approach to addressing issues of
resource reservation / locking in distributed architectures. While this
particular specification is of course for a Java implementation of the
concept, there's no reason the idea couldn't be incorporated into a
protocol like WebDAV.

> During the creation of the spec., we had discussions about whether to
> support different kinds of lock refresh policies, and potentially having
the
> ability to say whether the timeout was absolute, or could be refreshed by
> actions on the resource.  In the end, the spec. states that locks should
be
> refreshed by actions on the resource by the lock owner, but this hasn't
been
> widely implemented (to the best of my knowledge), since it adds a fair
> performance penalty to all operations.  There is currently an item on the
> DAV issues list "LOCK_REFRESH_BY_METHODS" that suggests the current
> SHOULD-level requirement for refreshing the lock timer based on actions by
> the lock owner should be removed.  However, it is this notion of locks
being
> refreshed by user activity that results in the mention of "activity-based
> timeout policy" in 8.10.8.

For all the reasons you cite, and *particularly* because the loosely
specified semantics of "implicit" refreshes breed interoperability
problems, a lease-like mechanism may be worth investigating.

-- Kaelin

Received on Monday, 24 January 2000 14:23:39 UTC