Transaction Recovery - Firebird

gfix provides tools for recovering transactions left in limbo after a connection is lost during a multi-database transaction.

Two-Phase Commit

A transaction that spans multiple Firebird databases is committed in two steps, or phases. This two-phase commit guarantees that, if the transaction cannot complete the updates to all of the databases involved, it will not update any of them.

In the first phase of a two-phase commit, Firebird prepares a sub-transaction for each database involved in the transaction and writes the appropriate changes to each database.

In the second phase, following the same order in which it prepared and wrote them, Firebird marks each sub -transaction as committed.

Limbo Transactions

Limbo transactions are sub-transactions that remain unresolved if something traumatic happens to one or more database connections during the second phase of the two-phase commit, for example, a network fault or a power failure. The server cannot tell whether limbo transactions should be committed or rolled back.

Consequently, some records in a database may become inaccessible until explicit action is taken to resolve the limbo transactions with which they are associated.

Transaction Recovery

With gfix, you have a number of options for inquiring about and resolving limbo transactions after the traumatic failure of a two-phase commit. The process of identifying a limbo transaction and either committing it or rolling it back is known as transaction recovery.

You can attempt to recover all limbo transactions or you can perform the recovery, transaction by transaction, using the transaction ID of each individual transaction.

Finding Limbo Transactions

To list the IDs of all limbo transactions, along with an indication of what would happen to each if an automatic two-phase recovery were requested, use the –l[ist] switch (that’s “l” as in “list”):

gfix -l db_name

Prompting for Recovery

Use the –p[rompt] switch together with –l[ist] to have gfix list the limbo transactions one by one and prompt you for COMMIT or ROLLBACK action:

gfix -l -p db_name

Automated Two-Phase Recovery

Since limbo transactions result from either failed commits or failed rollbacks, the server knows how each should end. Hence, automatic recovery is merely a way of confirming that you want gfix to proceed with the original intentions as they stood when the two-phase commit was interrupted.

The –t[wo_phase] {ID | all} switch initiates an automated two-phase recovery. Use all to perform a two-phase recovery for all limbo transactions:

gfix -t all db_name

Use the ID option by entering the transaction ID of a single transaction for which you want a two-phase recovery performed:

gfix -t nnnnnn db_name

where nnnnnn is the ID of the targeted transaction.

Specifically Committing or Rolling Back

To attempt to resolve limbo transactions by committing them, use the –c[ommit] {ID | all} switch. To recover all limbo transactions in this manner, enter

gfix -c all db_name

To resolve a single limbo transaction by attempting to commit it, enter

gfix -c nnnnnn db_name

where nnnnnn is the ID of the targeted transaction.

To attempt to resolve limbo transactions by rolling them back, use the –r[ollback] {ID | all} switch. To recover all limbo transactions in this manner, enter

gfix -r all db_name

To resolve a single limbo transaction by attempting to roll it back, enter

gfix -r nnnnnn db_name

where nnnnnn is the ID of the targeted transaction.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Firebird Topics