Subject Read Committed No Wait transactions
Author Ann W. Harrison
Ever since I heard of it, I've thought that a read
committed, no wait transaction was an abomination
in the sight of the concurrency gods.

The effect is to cause the transaction to fail with
an apparent deadlock if there are any uncommitted
records in the data set examined.

Does anybody
have any idea what it might possibly be good for?



This can be seen in very simple cases:

In one window, create a database, a table, and store one
record without committing it.

> qli
QLI> create database caine:\harrison\foo.gdb
QLI> define relation t1 f1 long;
QLI> store t1
Enter F1: 1

In another window, connect and start a no wait, read committed transaction,
then try to read the table you just stored into.

> isql
SQL> connect caine:\harrison\foo.gdb;
Database: caine:\harrison\foo.gdb
SQL> set transaction no wait read committed;
Commit current transaction (y/n)?y
SQL> select * from t1;

Statement failed, SQLCODE = -901

lock conflict on no wait transaction

If you commit the transaction in the qli session and reissue the
select in the isql window, it will succeed. Store another uncommitted
record in the qli window and the next isql select fails.