Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site u1100a.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!pyuxww!u1100a!sdo
From: sdo@u1100a.UUCP (Scott Orshan)
Newsgroups: net.arch
Subject: Re: Locking, again
Message-ID: <792@u1100a.UUCP>
Date: Thu, 14-Mar-85 10:06:31 EST
Article-I.D.: u1100a.792
Posted: Thu Mar 14 10:06:31 1985
Date-Received: Sat, 16-Mar-85 02:20:46 EST
References: <1685@seismo.UUCP>
Reply-To: sdo@u1100a.UUCP (Scott Orshan)
Organization: Bell Communications Research, Piscataway, NJ
Lines: 27

In article <1685@seismo.UUCP> mo@seismo.UUCP (Mike O'Dell) writes:
>
>(2) One of the most difficult issues is what people expect locks to mean.
>In particular, when a process dies some horrid death while holding a lock,
>(segmentation violation, inadvertent gunning-down by an aberant operator),
>what should happen?  If the lock means a simple append was being done,
>they breaking the lock is probably OK, if not desirable.  But if the
>lock means "the database b-tree is inconsistant", then breaking the lock is
>the last thing you want to do.

There are ways to manipulate B-trees (or slight modifications)
such that they are NEVER inconsistent.  This assumes that disk writes
are atomic - either nothing gets written or an entire block gets written.
If this is not true, then you need to have two copies of the tree
which get updated in a well defined sequence such that one of them
is always consistent even if a write fails in the middle.

We once had a database implemented this way where a shadow driver
provided the duplication of I/O without the database code's awareness.
Obviously, all writes must be immediate - not delayed in the buffer cache.

-- 

			Scott Orshan
			Bell Communications Research
			201-981-3064
			{ihnp4,allegra,bellcore,pyuxww}!u1100a!sdo