Manually recovering indoubt transactions

If you cannot wait for resynchronization to automatically resolve indoubt transactions, you can resolve the indoubt transactions manually. This process is sometimes referred to as heuristic processing.

For example, the communications link between the external transaction manager and a federated transaction manager fails in the middle of a transaction. If you have enough information about the transaction, you can free resources on the federated server and on remote data sources by rolling back the transaction from the federated server.

Use heuristic processing only when you know the reason for the transaction failure, and you must free locked resources immediately. In most situations, let the automated resynchronization recover transactions. There are multiple layers of transaction management in a federated system. Recovering transactions heuristically is a complex and potentially risky process.

There are three basic ways to perform heuristic processing:
  • The LIST INDOUBT TRANSACTIONS command

    You can use this command line command to perform heuristic processing.

  • The Indoubt Transaction Manager window

    You can use this graphical user interface tool to perform heuristic processing.

  • Heuristic APIs

    You can use these APIs within your applications to perform heuristic processing.

The specific operations and tasks that you use to perform heuristic processing varies, depending on the circumstances of the error.

In federated systems, when a heuristic processing request is sent to a federated transaction manager, the resulting decision to commit or roll back must be compatible with the actual status of the indoubt transaction on the federated server. Otherwise, an error message is returned.

The status of federated two-phase commit in doubt transactions is slightly different than basic two-phase commit in doubt transactions:

  • A status of (d) means that the transaction is missing commit acknowledgement from one or more federated data sources.
  • A status of (b) means that the transaction is missing rollback acknowledgement from one or more federated data sources.

If you cannot successfully commit or rollback a transaction with status (d) or (b), you can specify that the transactions be forgotten by using option (f). However, when you use the (f) option, all records of the transaction are erased from the federated server and you must manually clean up any remaining synchronization problems on the involved data sources. Only use the (f) option when it is absolutely necessary, such as when a remote server crashes or connections to remote servers are dropped and there is an urgent requirement to free up resources and use it with caution.

Note: Because the (d) and (b) statuses are new for WebSphere® Federation Server v9.1, down-level federated clients cannot support them. If you use a down-level client to manually recover indoubt transactions, the (d) and (b) statuses are mapped to status (m), instead, which is not an accurate value. To prevent inaccurate information when you are manually recovering indoubt transactions, be sure to use a v9.1 federated client. By default, the computer that runs WebSphere Federated Server v9.1 includes the v9.1 federated client.