2.5.5 Transaction Recovery - Remote Transaction Manager
This use case shows how the transaction manager drives recovery where a connection to a subordinate transaction manager breaks down during the two-phase commit protocol, as described in [GRAY], when a participant has completed Phase One but has experienced a failure before completing Phase Two. The participant uses this use case to recover the outcome of such transactions.
Context of use: There is a failure during the two-phase commit process, and the transaction is in an in-doubt state in the participant's log.

Figure 10: Use case for transaction recovery by a transaction manager
Goal: To recover the state of an in-doubt transaction in the participant's log.
Actors:
Remote transaction manager: The remote transaction manager is a primary actor. It is a transaction manager that receives a request to perform some transaction depending on its availability and enlists itself with the root transaction manager.
Root transaction manager: The root transaction manager is a supporting actor. It is a service that coordinates the lifetime of transactions, enabling resource managers to enlist in these transactions and to enlist in transactions that are coordinated by remote transaction managers. Here, a root transaction manager is a transaction manager that creates and starts the transaction.
Stakeholders:
Architects: An architect is responsible for the overall design of a system while managing the technical risks that are associated with it. An architect can use transaction processing services to provide proven, reusable support for distributed transactions.
IT operations personnel: If there are transactions in an in-doubt state in a resource manager log, the resource manager executes this use case to recover the affected transactions. Similarly, if a transaction manager has any transactions in a failed-to-notify state, a resource manager executes this use case to receive the outcomes of those transactions. Both of these operations can require manual intervention by the IT operations personnel to trigger the recovery or to force the affected resource managers and transaction managers to forget the transactions in the in-doubt and failed-to-notify states.
Preconditions:
Transaction processing services are operational.
The resource manager can access a transaction manager in the system.
The resource manager has transactions in an in-doubt state in its log.
Main Success Scenario:
Trigger: The remote transaction manager triggers this use case on startup if it has any in-doubt transactions in its log, as described in [MS-DTCO] section 1.3.4.2.
The remote transaction manager initiates a CheckAbort connection with the root transaction manager and sends a Check message to determine whether the transaction is aborted.
The root transaction manager returns the state of the transaction if it has a record of the transaction in its own log. Otherwise, the root transaction manager indicates to the resource manager that it does not have a record for the transaction.
The remote transaction manager either aborts or commits each transaction on the basis of the outcome information that it received from the root transaction manager. If the root transaction manager indicated that it does not have a record for a transaction, the remote transaction manager assumes that the transaction has been aborted.
Postcondition: The remote transaction manager durably updates its records, according to the outcome that it received from the root transaction manager.
Extensions: None.