2.5.6.3 Perform Transaction Work with Pull Propagation – Application

  • Article

In this use case, the application performs transaction work with pull propagation.

Context of use: To perform a set of operations in a transaction on a remote resource manager that has a separate transaction manager.

Goal: To perform transaction work with pull propagation on a remote resource that has a separate transaction manager.

Actors:

Application: The application is a primary actor that performs transaction work on a number of resource managers. The application creates a transaction, and therefore, only that application has the right to commit the transaction.

Application service: The application service is a supporting actor. It is a service that accepts requests to perform transaction work on local resource managers. An application service does not have the right to commit transactions.

Root transaction manager: The root transaction manager is a supporting actor. The root transaction manager coordinates the lifetime of transactions by providing functionality for resource managers to enlist in these transactions. The root transaction manager also provides functionality to enlist in transactions that are coordinated by remote transaction managers.

Remote transaction manager: The remote transaction manager is a supporting actor that receives requests to perform transactions depending on its availability.

Remote resource manager: The remote resource manager is a supporting actor that enlists with the remote transaction manager.

Stakeholders:

  • Architects

  • Implementers

Preconditions:

  • Transaction processing services are operational.

  • The application can access a transaction manager in the system.

  • The resource manager of the resource and the application service are on a remote computer and can access a transaction manager in the system.

  • The two computers involved are connected on a network.

  • The two transaction managers are on separate computers and can access each other.

  • The transaction managers on each computer in the system are operational.

Main success scenario:

  1. Trigger:  The application triggers the resource manager to update its resource in the context of the transaction that was created in the Create a Transaction (section 2.5.6.1) use case.

  2. The application sends the transaction reference that was received during the Create a Transaction use case, along with information about the work to be done to the application service.

  3. Upon receiving the information about the transaction reference and the work to be done, the application service asks its remote transaction manager to pull the transaction, passing the transaction reference that was provided by the application.

  4. The remote transaction manager sends a transaction reference to the root transaction manager asking to pull the transaction.

  5. The root transaction manager enlists the remote transaction manager in the transaction and returns success.

  6. The application service passes the information about the work to be done to the remote resource manager along with a reference to the transaction.

  7. The remote resource manager executes the Enlist in a Transaction (section 2.5.6.2) use case, requesting that the remote transaction manager enlist it in the transaction.

  8. The remote resource manager makes the requested updates to the resource in accordance with the two-phase commit protocol semantics, such as isolation and durability.

  9. The remote resource manager reports success to the application service, and in turn, the application service reports success to the application.

Postcondition: Transaction work is done with pull propagation.

Extensions: None.

Variation – perform transaction work with pull propagation – external application: All details are identical to the use case as described in this section except that the application here is an external application that makes use of optional protocols (see section 2.2).