Recovering transactions: Use cases

There are several different use cases from which transactions might need to be recovered.

• IBM MQ Application using single DTC and single Queue Manager instance: In this use case, when you connect to the queue manager and run Unit of Work (UoW) under transaction, and if the transaction fails and becomes incomplete, the monitor application recovers the transaction and completes it.

  In this use case, there will be a single instance of monitor application running, as a single Queue manager is associated with the transactions.

• Multiple IBM MQ Applications using single DTC and single Queue Manager instance: In this use case, there are more than one WMQ applications under single DTC and all are connecting to the same queue manager and running UoW under transactions.

  If the transactions fail and become incomplete, the monitor application recovers them and completes the transactions pertaining to all the applications.

  In this use case, a single monitor application runs, as one queue manager is used in transactions.

• Multiple IBM MQ Applications, multiple DTCs, different Queue Manager instances: In this use case, there are more than one WMQ applications under different DTCs (that is, each application is running on a different machine) and connecting to different queue managers.

  If failure occurs and transaction becomes incomplete, monitor application checks the TransactionManagerWhereabouts in the message to determine the DTC address. If the TransactionManagerWhereabouts value matches with the DTC address under which the monitor is running, it completes the recovery, else, it continues to search until the message corresponding to its DTC is found.

  In this use case, there will be only one instance of monitor application running per client (user or computer) as each client has its own queue manager used in transactions.

• Multiple IBM MQ Applications, multiple DTCs, multiple same Queue Managers instances: In this use case, there are more than one WMQ applications under different DTCs (that is each application is running on a different machine) and all are connecting to same queue manager.

  If failure occurs and transaction becomes incomplete, monitor application verifies the TransactionManagerWhereabouts in the message to check if the DTC address and value match with the DTC under which the monitor is running. If both the values match, it completes the recovery else continues to search until it finds the message corresponding to its DTC.

  In this use case, there will be only a single instance of monitor application running per client (user or computer), as each client has its own queue manager association used in transactions.

• Multiple IBM MQ Applications, single DTC, different Queue Manager instances: In this use case, there are more than one WMQ applications under a single DTC (that is, on a computer, there are more than one WMQ applications running) and connecting to different queue managers.

  If transaction fails and becomes incomplete, monitor application recovers the transaction.

  In this use case, there will be as many instances of monitor application running as queue managers connected to, as each application has its own queue manager used in transactions and each of it must be recovered. Note: If the monitor application is not running in the background, we can start it.

Parent topic: Recovering transactions in IBM MQ .NET