🚀 go-pugleaf

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

In article <1621@utah-gr.UUCP> peter@utah-gr.UUCP (Peter S. Ford) writes:
>>  ...  It is not surprising to me that IBM DB2 opted for an implicit 
>>  locking scheme.

DB2 supports both an implicit and an explicit locking scheme.  The explicit
locking capabilities include the SQL statement LOCK TABLE, the isolation
level option of the BIND command, and the tablespace "lockable unit"
parameter.

Darryl Olson
uw-beaver!teltone!dataio!olson

 If you can help with this, please do; send me a phone number if you'd 
 prefer and I will call you.

 I am interested in purchasing RTI's "commercial" Ingres; it seems to do what
 we want.

 HOWEVER, I have received feedback from current users, particularly those own-
          ing VAX/VMS systems, that response time degrades inordinately when
          multiple users are accessing Ingres concurrently - both the package
          and the system slows down more so than with other DBMS's.

 I would appreciate any experience in this area that you may have had with RTI's
 Ingres on Unix-based systems. I would especially like to hear from those who
 have comparisons to Oracle.

    thank you, greg pavlov, fstrf, amherst, n.y., 716-837-4000


 P.S.: we evaluated a number of systems in the past 6 months and simulated mul       user environments to see how each system held up.  We would do the same
       with Ingres. BUT the port to our machine, an  HP9000 series 500, is not
       ready yet.  So I was forced to evaluate it on a VAX750/VMS system.

> 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