W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1996

Re: Lock timeouts revisited -Reply -Reply

From: Steve Carter <srcarter@novell.com>
Date: Tue, 08 Oct 1996 10:16:38 -0600
Message-Id: <s25a2a30.051@novell.com>
To: gramlich@bigbang.Eng.Sun.COM
Cc: w3c-dist-auth@w3.org
Another thought on your thought Wayne. GroupWise 5 does not use a
local (or remote) file lock. The lock it a part of the DMS and does not
depend on any kind of file system. My comment was in reguard to the
general case of "locking" not specifically to the issue of file locking.

Steve Carter

>>> Wayne C. Gramlich <gramlich@bigbang.Eng.Sun.COM> 10/02/96
06:42pm >>>
> From srcarter@novell.com Wed Oct  2 07:52:30 1996
> A DMS must have a lock that is persistent over time. The concept of a
> non-persistent lock is only valid during an on-line editing session (as
> opposed to a checked-out document). If we do specify lock time-out as
> property of locking we must also define what the behavior of the lock
> will be if the document repository does not support a lock time-out
> feature.


While some DMS systems out there are designed around file locking,
it is possible to have a fully functional remote DMS that does not
use remote file locking.  The Sun Teamware product is one such DMS.
While Teamware is layered on top of SCCS (which has local file locking),
the distributed authoring component of Teamware does not use remote
file locks.  Thus, the statement that "A DMS must have a lock that
is persitent over time." should probably be restated to say  "Some
DMS's need persistent locks."  Given the difficulty of managing remote
locks, it may be appropriate to investigate a dist. authoring
architecture that avoids the remote locking issue entirely.

Received on Tuesday, 8 October 1996 12:16:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:09 UTC