2.5.1 Perform Transaction Work – Application

In this use case, the application performs the transaction between multiple transaction managers.

Context of use: An application performs transaction work across multiple transaction managers.

Figure 6: Use case diagram for performing transaction work

Goal: To perform transaction work between a root transaction manager and one or more remote transaction managers.

Actors:

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

Root transaction manager: The root transaction manager is a supporting actor. It is a service that 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. A root transaction manager is a transaction manager that creates and starts the transaction.

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

Resource manager: The resource manager is a supporting actor 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 (here it is the root transaction manager) to vote on that transaction outcome and to obtain the final outcome.

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

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 cannot commit transactions.

Stakeholders:

Application: The application is a program that creates transactions in a distributed computed network. Only that application has the right to commit the transaction.

Preconditions:

• Transaction processing services are operational.

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

Main success scenario:

1. Trigger: The application triggers the root transaction manager to create a transaction (section 2.5.6.1).

2. The resource managers enlist in a transaction (section 2.5.6.2) with their respective root transaction manager and remote transaction manager or transaction managers.

3. After successful enlistment in a transaction, the resource manager or managers make the requested updates to their resource in accordance with the semantics of the two-phase commit protocol, such as isolation and durability.

4. The application performs remote transaction work with pull propagation by using the application service (section 2.5.6.3).

Postcondition: The transaction is performed successfully.

Extensions: None.

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