Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!qantel!dual!lll-crg!seismo!harvard!sasaki
From: sasaki@harvard.ARPA (Marty Sasaki)
Newsgroups: net.database
Subject: locks
Message-ID: <341@harvard.ARPA>
Date: Mon, 9-Sep-85 15:09:46 EDT
Article-I.D.: harvard.341
Posted: Mon Sep  9 15:09:46 1985
Date-Received: Fri, 13-Sep-85 05:06:53 EDT
References: <10185@ucbvax.ARPA> <5909@utzoo.UUCP> <10233@ucbvax.ARPA>
Reply-To: sasaki@harvard.UUCP (Marty sasaki)
Organization: Harvard Science Center
Lines: 18

This got beaten to death a while ago in net.arch, but let me add my
two cents.  I believe that the issue of database locking is too
complicated to be done in the operating system.  The best thing to do
would be to provide a simple, easy to use, efficient, lock mechanism
in the operating system. A database daemon, or a magic device driver
could then implement the desired scheme for the database using the
primitives provided by the system.

VMS (no flames please) has such a lock manager. The idea is that locks
are named when they are created. There are primities to lock, unlock,
and wait on locks. All that is required is that users agree on a
naming scheme for the locks.
-- 
----------------
  Marty Sasaki				net:   sasaki@harvard.{arpa,uucp}
  Havard University Science Center	phone: 617-495-1270
  One Oxford Street
  Cambridge, MA 02138