On Mon, May 13, 2019 at 5:08 AM Rustam rusta...@ukr.net [firebird-support] <
firebird-support@yahoogroups.com> wrote:
>
>
> 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
>
>
>
>
