IBM MQ .NET Distributed Transaction Processing - Recovering Transaction
This section describes how transactions can be recovered with IBM MQ .NET classes.
Overview
To recover an incomplete transaction the recovery information is required. The transaction recovery information must be logged to storage by the resource managers. IBM MQ .NET classes follow a similar path. The transaction recovery information is logged to a system queue called SYSTEM.DOTNET.XARECOVERY.QUEUE.
Transaction recovery in IBM MQ .NET is a two stage process.
-
Logging of transaction recovery information.
- For every transaction, during the prepare phase a persistent message containing the recovery information is added to SYSTEM.DOTNET.XARECOVERY.QUEUE.
- The message is deleted if the commit call succeeds.
-
Recovering transactions using a monitor application WmqDotnetXAMonitor.
- WmqDotnetXAMonitor is a .NET managed application that processes messages in SYSTEM.DOTNET.XARECOVERY.QUEUE and recovers incomplete transactions
If the MCA is unable to put the message to the destination queue, it generates an exception report containing the original message, and puts it on a transmission queue to be sent to the reply-to queue specified in the original message. (If the reply-to queue is on the same queue manager as the MCA, the message is put directly to that queue, not to a transmission queue.)
SYSTEM.DOTNET.XARECOVERY.QUEUE
This is a system queue that holds transaction recovery information of incomplete transactions. This queue gets created when a queue manager is created.
Note: We should not delete SYSTEM.DOTNET.XARECOVERY.QUEUE queue.WMQDotnetXAMonitor Application
IBM MQ .NET XA Monitor application monitors a given queue manager and recovers incomplete transactions if any. Following are deemed as incomplete transactions and are recovered:
Incomplete Transactions- If the transaction is prepared but COMMIT did not complete within the timeout period.
- If the transaction is prepared but IBM MQ Queue manager has gone down.
- If the transaction is prepared but then Transaction Manager has gone down.
Monitor application must be run from the same system where the IBM MQ .NET client application is running. If there are applications running on multiple systems connecting to the same queue manager, the monitor application must be run from all the systems. Though each client machine has a monitor application running to recover the application, each monitor should be able to identify the message that corresponds to transaction that the current monitor's local MS DTC was coordinating so that it can reenlist and complete it.
Parent topic: Recovering transactions in IBM MQ .NET