3.3.4.15 Resolving a Transaction

  • Article

If the higher-layer business logic determines that it needs to manually resolve the outcome of a transaction, the application MUST perform the following steps:

  • If the transaction is not in either the Failed to Notify (section 3.2.1.3.13) or the In Doubt (section 3.2.1.3.12) state:

    • Return a failure result to the higher-layer business logic.

  • Otherwise:

    • Initiate a new CONNTYPE_TXUSER_RESOLVE (section 2.2.8.3.2) connection using the Transaction Manager Name field of the application.

    • If the transaction is in the Failed to Notify (section 3.2.1.3.13) state:

      • Send a TXUSER_RESOLVE_MTAG_FORGET_COMMITTED (section 2.2.8.3.2.5) message using the connection:

        • The guidTx field MUST be set to the Transaction Object.Identifier of the provided transaction.

      • Set the connection state to Awaiting Forget Response (section 3.3.1.11.3).

    • Otherwise, if the transaction is in the In Doubt (section 3.2.1.3.12) state:

      • If the higher-layer business logic wants to manually resolve the transaction outcome as Commit:

        • Send a TXUSER_RESOLVE_MTAG_CHILD_COMMIT (section 2.2.8.3.2.3) message using the connection:

          • The guidTx field MUST be set to the Transaction Object.Identifier of the provided transaction.

        • Set the connection state to Awaiting Commit Response (section 3.3.1.1.4).

      • Otherwise, if the higher-layer business logic wants to manually resolve the transaction outcome as Abort:

        • Send a TXUSER_RESOLVE_MTAG_CHILD_ABORT (section 2.2.8.3.2.2) message using the connection:

          • The guidTx field MUST be set to the Transaction Object.Identifier of the provided transaction.

        • Set the connection state to Awaiting Abort Response (section 3.3.1.1.5).