Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site uwmcsd1.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!uwmcsd1!jerry
From: jerry@uwmcsd1.UUCP (Jerry Lieberthal)
Newsgroups: net.database
Subject: Re: locks
Message-ID: <410@uwmcsd1.UUCP>
Date: Mon, 9-Sep-85 22:54:06 EDT
Article-I.D.: uwmcsd1.410
Posted: Mon Sep  9 22:54:06 1985
Date-Received: Wed, 11-Sep-85 05:35:57 EDT
References: <10185@ucbvax.ARPA> <5909@utzoo.UUCP> <10233@ucbvax.ARPA> <341@harvard.ARPA>
Organization: U of Wi-Milwaukee, Computing Services Div
Lines: 31

> 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
> 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
>   One Oxford Street
>   Cambridge, MA 02138

This is also true of the Sperry implementation (DMS 1100) which is a
network arch. database with locks around the world (maybe that's why
users spend so much of their time locking/unlocking that the update never
gets done :-)).  The locks are implemented in the equivalent of a daemon
and not really in the OS (although Sperry has hooks there too if you want
to use them).

-- 


------------------------------------------------

	- jerry     University  of Wisconsin-Milwaukee
		    Computing Services Division
		    ihnp4!uwmcsd1!jerry
		    uwmcsd1!jerry@wisc-rsch.ARPA

"HALT, or  you will exterminateeedddd......" <sounds of meltdown follow>
|
|
|-------> sound  of generic DALEK fadeout ...