jmc@ptsfa.UUCP (Jerry Carlin) (10/30/85)
From Datamation, October 15 issue, page 13:
"... Notably absent so far from [DB2] has been an effective record-level
locking feature that is critically important for performing simultaneous
updates to a single database."
And we thought that only Unix DBMS's had problems with record locking :-)
--
voice= 415 823-2441
uucp={ihnp4,dual,qantel}!ptsfa!jmceric@osiris.UUCP (Eric Bergan) (10/31/85)
> From Datamation, October 15 issue, page 13: > > "... Notably absent so far from [DB2] has been an effective record-level > locking feature that is critically important for performing simultaneous > updates to a single database." > > And we thought that only Unix DBMS's had problems with record locking :-) Also from that same article, it reports that DB2 is averaging 3 to 5 transactions per second on a mainframe. It goes on to quote the same sources as saying they see 80 tps from IMS. The last numbers I saw for Ingres on a supermini indicated it could handle around 10 tps. -- eric ...!seismo!umcp-cs!aplvax!osiris!eric
rmarti@sun.uucp (Bob Marti) (11/01/85)
> >From Datamation, October 15 issue, page 13: > > "... Notably absent so far from [DB2] has been an effective record-level > locking feature that is critically important for performing simultaneous > updates to a single database." > > And we thought that only Unix DBMS's had problems with record locking :-) According to Chris Date's book "A Guide to DB2", DB2 does implicit record- level locking inside transactions. It turns out, however, that depending on some "lockable unit" system parameter, locking a record implies one of the following: - locking of the page where the record is physically stored - locking of the tablespace (a set of tables defined by the DBA) to which the record belongs The parameter can be set to PAGE, TABLESPACE, or ANY. In the latter case, DB2 decides for itself what it thinks is best for a given access plan. If you want to know more about locking in DB2 see chapter 11 in Date's DB2 book. --Bob Marti {decvax, ucbvax, seismo}!sun!rmarti
peter@utah-gr.UUCP (Peter S. Ford) (11/05/85)
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
olson@dataioDataio.UUCP (Darryl Olson) (11/06/85)
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
bc@cyb-eng.UUCP (Bill Crews) (11/12/85)
> 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