Resolving indoubt transactions manually
An XA-compliant transaction manager (Transaction Processing Monitor) uses a two-phase commit process similar to that used by the Db2® transaction manager. The principal difference between the two environments is that the TP monitor provides the function of logging and controlling the transaction, instead of the Db2 transaction manager and the transaction manager database.
Errors similar to those that occur for the Db2 transaction manager can occur when using an XA-compliant transaction manager. Similar to the Db2 transaction manager, an XA-compliant transaction manager attempts to resynchronize indoubt transactions.
If you cannot wait for the transaction manager to automatically resolve indoubt transactions, you can manually resolve them. This manual process is sometimes referred to as making a heuristic decision.
About this task
The LIST INDOUBT TRANSACTIONS command
(using the WITH PROMPTING option), or the related
set of APIs (db2XaListIndTrans, sqlxphcm, sqlxhfrg, sqlxphrl),
allows you to query, commit, and roll back indoubt transactions. In
addition, it also allows you to forget
transactions that were
heuristically committed or rolled back, by removing the log records
and releasing the log space.
Manually resolve indoubt transactions by using these commands (or related APIs) with extreme caution, and only as a last resort. The best strategy is to wait for the transaction manager to drive the resynchronization process. You could experience data integrity problems if you manually commit or roll back a transaction in one of the participating databases, and the opposite action is taken against another participating database. Recovering from data integrity problems requires you to understand the application logic, to identify the data that was changed or rolled back, and then to perform a point-in-time recovery of the database, or manually undo or reapply the changes. If you cannot wait for the transaction manager to initiate the resynchronization process, and you must release the resources tied up by an indoubt transaction, heuristic operations are necessary. This situation could occur if the transaction manager will not be available for an extended period of time to perform the resynchronization, and the indoubt transaction is tying up resources that are urgently needed. An indoubt transaction ties up the resources that were associated with this transaction before the transaction manager or resource managers became unavailable. For the database manager, these resources include locks on tables and indexes, log space, and storage taken up by the transaction. Each indoubt transaction also decreases (by one) the maximum number of concurrent transactions that can be handled by the database. Moreover, an offline backup cannot be taken unless all indoubt transactions have been resolved.
- When a heuristically committed or rolled back transaction causes a log full condition, indicated in output from the LIST INDOUBT TRANSACTIONS command
- When an offline backup is to be taken
missinglog record implies that the resource manager has rolled back the transaction.
Procedure
To resolve indoubt transactions manually:
What to do next
To obtain indoubt transaction information from Db2, connect to the database and issue the LIST INDOUBT TRANSACTIONS WITH PROMPTING command, or call the db2XaListIndTrans API from a client application.