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?


Regards,


Ann

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
QLI>

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
Committing.
SQL> select * from t1;

F1
============
Statement failed, SQLCODE = -901

lock conflict on no wait transaction
-deadlock
SQL>

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.