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