Ann W. Harrison wrote:

> When a transaction inserts, updates, or deletes a record, it creates
> a record version with its transaction id in the header. When another
> transaction attempts to update or delete the record, it checks the
> transaction id in the header of the newest record version. If that
> transaction is active (in the case of read committed) or was active
> when the current translation started (in the case of snapshot or
> concurrency transactions) the operation fails with a deadlock - update
> conflict error.
>
> There are no row level locks.
>

Let me clarify a bit more. What I should have said is:

When another transaction attempts to update or delete the record,
it checks the transaction id in the header of of the most recent
version.

If the updating transaction is snapshot/concurrency and the
transaction identified by the newest record version was active
when the updating transaction started, then the updating transaction
checks the state of the transaction that created the record version.
Depending on the states of the transactions the results are:

1) If the transaction that created the record version rolled back, the
updating transaction cleans out the rolled back version and proceeds.

2) If the transaction that created the record version committed, the
updating transaction gets a deadlock update conflict error.

3) If the transaction that created the record version is in limbo,
the updating transaction gets a deadlock update conflict with
limbo transaction error.

4) If the transaction that created the record version is active
and the updating transaction is no wait, the updating transaction
gets a deadlock update conflict with no wait transaction error.

5) If that transaction is active and the updating transaction is
wait, it waits for the transaction that made the update to finish,
and goes into case 1, 2, 3, or 4, depending on states.

If the updating transaction is read committed

1) and the transaction that created the record version is committed, the
operation succeeds.

2) and the transaction that created the record version is rolled back,
the updating transaction cleans out the old version and its operating
succeeds.

3) and the transaction that created the record version is in limbo,
the operation fails with a deadlock update conflict with limbo
transaction error.

4) If the transaction that created the record version is active
and the updating transaction is no wait, the updating transaction
gets a deadlock update conflict with no wait transaction error.

5) If that transaction is active and the updating transaction is
wait, it waits for the transaction that made the update to finish,
and goes into case 1, 2, 3, or 4, depending on states.


Regards,