At 12:36 PM 9/21/2004, Jonathan Neve wrote:

> >The effect is to cause the transaction to fail with
> >an apparent deadlock if there are any uncommitted
> >records in the data set examined.
> >
> >
>Are you sure this isn't the behaviour when combined with another TR
>option?

Yes, I'm quite certain that if a read committed no wait transaction
encounters a record that has been written (inserted, updated, or deleted)
and not committed it will get an immediate deadlock error, whether
the transaction that did the write is read committed, snapshot,
wait, or no wait.

> In my experience, the effect is rather to fail immediately
>(without waiting) if any other transaction tries to UPDATE a record
>that's already been updated in a different transaction.

It demonstrably fails with ISQL when attempting to read an
uncommitted record.

>I don't understand how you can get such an effect. Isn't this behaviour
>specific to a combination with another option?

Here are two ISQL sessions, both using read committed, no wait
transactions.

In window 1:

SQL> set transaction no wait read committed;
Commit current transaction (y/n)?y
Committing.
SQL> insert into t1 values (4);
SQL>

In window 2:

SQL> set transaction no wait read committed;
Commit current transaction (y/n)?y
Committing.
SQL> select * from t1;

F1
============

1
2
3
Statement failed, SQLCODE = -901

lock conflict on no wait transaction
-deadlock
SQL>

> Isn't there an option
>that locks the record for both read and write access?

No or rather yes, there is an explicit record lock in FB1.5, but
these examples don't use it.


Regards,


Ann