Important notice: modified rows in that 'dead' transaction remains locked along this TA existence. So, your another connections will get 'lock conflict' errors ('no wait' TA's), or waiting forever ('wait' TA's) when try to modify same rows.
As Mark Rotteveel says below, if a connection is broken with an active transaction, Firebird will detect that the
connection and thus the transaction are dead and change the state of the transaction to dead. That will unblock
waiting transactions, etc. When Firebird detects a record level conflict, it first checks the state of the blocking
transaction, then if the transaction appears to be active, it checks the state of the connection. So in the case of
a network glitch or program exit without cleanup, Firebird will set the state of the blocking transaction to dead
without manual intervention.
On the other hand, if someone goes to lunch or on holiday with an application connected to the database and
a transaction with uncommitted change running, then manual cleanup is required. Also better program
discipline.
Even if you just want reconnect on unexpected connection lose and finish your previous work.
That doesn't happen.
For such extremal cases your application can present for SYSDBA special window that shows table with data from MON$ATTACHMENTS (login, connection's start date, client IP, app name).
Deleting record from MON$ATTACHMENTS will close connection, so you can continue.
Again, only necessary in the case where the connection remains active while the transaction is stalled.
Good luck,
Ann
The data isn't committed, so it isn't visible to any other transaction.
If a connection is closed with an active transaction, the transaction
will eventually be rolled back by Firebird. See also "“Dead”
transactions" in the Firebird book.
Mark Rotteveel