2.5.4 Recover In-doubt Transaction State – Resource Manager
This use case shows how the resource manager drives recovery when a connection to a resource manager breaks down after a participant has completed Phase One, but before completing Phase Two of the two-phase commit protocol, as described in [GRAY]. 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 root transaction manager's log.

Figure 9: Use case for transaction recovery by a resource manager
Goal: To recover the state of an in-doubt transaction in the root transaction manager's log.
Actors:
Resource manager: The resource manager is a primary actor which is a participant that is responsible for coordinating the state of a resource with the outcome of transactions. For a specified transaction, a resource manager enlists with exactly one transaction manager to vote on that transaction outcome and to obtain the final outcome.
Transaction manager: The transaction manager is a supporting actor. The transaction manager is a service that coordinates the lifetime of transactions by providing functionality for resource managers to enlist in these transactions. The transaction manager also provides functionality to enlist in transactions that are coordinated by remote transaction managers. Here, the root transaction is a transaction manager that creates the transaction and starts performing 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 the transaction processing services as an element of a system in the design process to provide reliable support for distributed transactions.
IT operations personnel: If there are transactions in an in-doubt state in the 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, then 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 either an in-doubt and failed-to-notify state.
Preconditions:
Transaction processing services is operational.
The resource manager can access a transaction manager in the system.
The resource manager has transactions in in-doubt state in its log.
Main success scenario:
Trigger: The resource 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 resource manager asks the transaction manager for the outcome of the transactions in an in-doubt state in its log.
The system returns the state of each transaction if it has a record of the transaction in its log. Otherwise, the transaction manager indicates to the resource manager that it does not have a record of the transaction.
The resource manager either aborts or commits each transaction on the basis of the outcome information that it received from the transaction manager. If the transaction manager indicates that it does not have a record for a transaction, the resource manager assumes that the transaction has been aborted.
Postcondition: The transaction manager forgets the transaction and the resource manager durably updates its records according to the outcome that it received from the transaction manager.
Extensions: None.