Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cyb-eng.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!pesnta!amd!amdcad!lll-crg!mordor!ut-sally!cyb-eng!bc
From: bc@cyb-eng.UUCP (Bill Crews)
Newsgroups: net.database
Subject: Re: IBM DB2 lacks record locking
Message-ID: <784@cyb-eng.UUCP>
Date: Tue, 12-Nov-85 12:39:54 EST
Article-I.D.: cyb-eng.784
Posted: Tue Nov 12 12:39:54 1985
Date-Received: Fri, 15-Nov-85 04:19:25 EST
References: <2953@sun.uucp> <1621@utah-gr.UUCP>
Distribution: net
Organization: Cyb Systems, Austin, TX
Lines: 17

> Deadlock and starvation are much more likely in systems where the programmer
> is left with full responsibilty for concurrency control.
> 
>                           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.

I agree with your point, and I think that as much implicit locking as possible
should be performed by the DBMS.  However, it also seems to me that the INTENT
of the programmer is crucial in many cases.  If one is simply accessing tuples
sequentially with no intent to update, the situation is quite different from
reading a tuple WITH INTENT to UPDATE (or delete) that tuple.  In fact, this
seems to me like basic stuff seen in most DBMSs today, no?
-- 
	- bc -

..!{seismo,topaz,gatech,nbires,ihnp4}!ut-sally!cyb-eng!bc  (512) 835-2266