Re: FREE_ALL locks

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Geoff Arnold (geoff.arnold@sun.com)
Date: 08/16/98-11:58:24 PM Z


Message-ID: <35D7B870.3F9B25AB@sun.com>
Date: Mon, 17 Aug 1998 00:58:24 -0400
From: Geoff Arnold <geoff.arnold@sun.com>
Subject: Re: FREE_ALL locks




Brent Callaghan wrote:

> > In order to release all the locks on client crash we need LOCKF
> > (FREE_ALL) request which is missing from the spec.
>
> I assume here that by "client" you're referring to an application
> or process running on a client machine.  Obviously if the client
> machine crashes it's not going to have much of an opportunity to
> blurt out a "free all my locks" as it crashes.
>
> Given that lock leases will eventually time out anyway, there's no strong case
> for cluttering up the protocol with yet another locking operation.

Sorry, Brent, I have to weigh in here. Exactly how long do you expect
lock leases to be? If they're too short, clients will have to keep
renewing long-lived locks.  If they're long, a "free_all" is a real
win.

In the old LM protocol we included a "free-all" because we used
long-lived locks to handle DOS file sharing modes.

With smarter servers, it might be worthwhile to generalize
the "free_all" call into a "flush all resources associated with
this client", including locks, cached structures, in-progress long
duration operations (think CD juke-box), etc. That way we wouldn't
be cluttering up the protocol with yet another locking operation :-)

Geoff



New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:08 AM Z CST