Transaction recovery process for WebSphere MQ .NET

This section describes how distributed transactions can be recovered with WebSphere 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. WebSphere 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 WebSphere MQ .NET is a two stage process.

  1. 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.
  2. 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: You should not delete SYSTEM.DOTNET.XARECOVERY.QUEUE queue.

WMQDotnetXAMonitor Application

WebSphere 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 WebSphere 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 your WebSphere 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.