Adam wrote:

>
> One thing of note is that record locks acquired after the savepoint
> declaration are not released during the rollback to savepoint
> operation, and this behaviour may (or may not) change in subsequent
> versions.

A rollback to a savepoint removes the record versions created. Since
Firebird doesn't use record locks but instead relies on the transaction
id in record versions, removing the record version is the same as
releasing the lock, except in one case.

When a transaction starts, it gets an exclusive lock on its own
transaction id. When a transaction attempts to modify a record and
discovers that the most recent version was created by a concurrent
transaction, it attempts to get a lock on the id of the transaction that
made the change. When it gets the lock, it checks the state of the
conflicting transaction. If that transaction rolled back, the waiting
transaction proceeds. If the conflicting transaction committed, the
transaction that had waited gets an "update conflict" error and must
rollback and retry the operation. (Read-committed transactions can
simply retry without the rollback - risking inconsistency, but no one
who cares about consistency uses read-committed.)

So the problematic case is that Transaction A created a save point then
updated some records. Transaction B attempts to update one of those
records, recognizes the conflict, and starts waiting for a lock on the
id of Transaction A. Transaction A's rolling back to the save point
has no effect on Transaction B. It continues to wait, even though there
is no longer a conflict. when Transaction A eventually commits,
Transaction B thinks it had an update conflict, and must roll back.

There's no convenient way for Transaction A to recognize that it has
unblocked Transaction B by undoing the save point.

This is annoying.

Regards,


Ann