Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site plus5.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!plus5!hokey
From: hokey@plus5.UUCP (Hokey)
Newsgroups: net.database
Subject: Re: file, record, field, and index locking
Message-ID: <862@plus5.UUCP>
Date: Wed, 18-Sep-85 12:16:05 EDT
Article-I.D.: plus5.862
Posted: Wed Sep 18 12:16:05 1985
Date-Received: Thu, 19-Sep-85 05:37:52 EDT
References: <56@ucdavis.UUCP> <6825@ucla-cs.ARPA>
Reply-To: hokey@plus5.UUCP (Hokey)
Distribution: net
Organization: Plus Five Computer Services, St. Louis, MO
Lines: 17

It is not always necessary to lock both the data file and the index file.

If one writes *consistent* software, it is only necessary to lock the
index file.

File locks should be *much* faster than record locks.  It is not always
true that one wishes to record-lock an m-tree (including B-tree) index,
because the overhead associated with log m (n) can be much greater than
simply locking the entire index.

Timings (tradeoffs) change based on availability of shared/promotable/exclusive
locks, or the availability of a single database server (which can also act as
a cache).

-- 
Hokey           ..ihnp4!plus5!hokey
		  314-725-9492