4.6.2 Reenlisting in In-Doubt Transactions

To reenlist in any transaction that is in-doubt, the resource manager establishes a CONNTYPE_TXUSER_REENLIST connection with its transaction manager.

CONNTYPE_TXUSER_REENLIST: The packet sequence starts when the resource manager initiates a CONNTYPE_TXUSER_REENLIST connection.

For each in-doubt transaction, the resource manager sends a TXUSER_REENLIST_MTAG_REENLIST user message specifying the transaction identifier (guidTx), the time-out (in milliseconds) that it will wait for notification, and the resource manager identifier (guidRm). For this sample, the resource manager will wait 1 second (or 1000 milliseconds).

When transaction manager receives the reenlist request, it attempts to find the transaction in its list of known transactions. If the transaction manager cannot locate the transaction, it assumes that the transaction aborted and replies to the resource manager with a TXUSER_REENLIST_MTAG_REENLIST_ABORTED user message.

If the transaction manager can locate the transaction, the transaction manager attempts to determine outcome. The transaction manager replies to the resource manager with a TXUSER_REENLIST_MTAG_REENLIST_COMMITTED or TXUSER_REENLIST_MTAG_REENLIST_ABORTED user message, as appropriate.

If the transaction manager is unable to determine outcome in the time-out period, the transaction manager replies to the resource manager with a TXUSER_REENLIST_MTAG_REENLIST_TIMEOUT user message.

After the resource manager determines the outcome from the transaction manager, it performs any remaining commit or abort work, as appropriate. If the resource manager receives a time-out notification, it needs to maintain the in-doubt entries in its log unchanged. The resource manager will attempt to determine the outcome of these in-doubt transactions next time it performs recovery.

For any remaining in-doubt transactions, the resource manager needs to perform the previous steps for each in-doubt transaction.

If there are no more in-doubt transactions, the resource manager informs the transaction manager that it has completed its recovery process. The resource manager then initiates the disconnect sequence on this connection.