Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-gr.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!utah-cs!utah-gr!peter
From: peter@utah-gr.UUCP (Peter S. Ford)
Newsgroups: net.database
Subject: Re: IBM DB2 lacks record locking
Message-ID: <1621@utah-gr.UUCP>
Date: Tue, 5-Nov-85 00:58:51 EST
Article-I.D.: utah-gr.1621
Posted: Tue Nov  5 00:58:51 1985
Date-Received: Thu, 7-Nov-85 05:46:56 EST
References: <2953@sun.uucp>
Reply-To: peter@utah-gr.UUCP (Peter S. Ford)
Distribution: net
Organization: University of Utah CS Dept
Lines: 23

In many ways explicit record locking is not a desirable feature.  Most 
serious (real?) database systems have several data structures which need 
concurrency control; the interrelation and application
of the concurrency control is best handled implicitly by the database system.
Deadlock and starvation are much more likely in systems where the programmer
is left with full responsibilty for concurrency control.

Other considerations support implicit concurrency control by the DBMS.
The database system may determine it better for overall throughput to 
lock a whole data structure (a single table, or an index) rather than
locking many smaller parts of the structure and clogging up access to 
a lock manager or table.  And finally, I like to think that one function
of a DBMS is to abstract away the problems of physical and temporal
access to data.

My bias in this direction is based on experience with the Britton Lee
Database machine which does implicit locking rather than having
explicit locking primitives.  It is not surprising to me that
IBM DB2 opted for an implicit locking scheme.

Peter Ford
University of Utah CS Department
peter@utah-cs