8.4 Distributed Transactional Operations

The occurrence of transactions in a distributed environment is quite common today. Distributed transactional operations are data updates to two or more databases by one or more applications or threads participating in the transaction. These types of transactions are usually implemented by using either a distributed-transaction model or the queued-transaction model. ^[1]

^[1] Distributed-access transactions are often viewed as distributed transactional operations even though only one database is involved in the transaction.

In this section, we describe both of these models and provide example architectures.

Distributed-Transaction Model

This model is typically implemented using remote procedure calls as a communication mechanism. Because RPCs are used for communication, requests are handled in a synchronous manner, and all participating applications or threads must be available at the time of the request. The distributed-transaction model assumes that a transaction will involve data updates to two or more databases by one or more applications or threads participating in the transaction. Typically, this model is implemented using a flat or nested transaction model with additional management for commit, rollback, resource locking, and access.

Commit and rollback functionalities are typically achieved using a two-phase commit protocol. This protocol ensures that the execution of data transactions is synchronized: All data updates are either committed or rolled back with respect to each of the distributed databases.

With this model, a transaction context is also maintained by the underlying transaction manager. It is this transaction context that ultimately defines a global transaction: a specific sequence of operationsthat is, operations performed on all databases involved in the transactionthat conform to the ACID properties.

Given the complexity of building distributed-transaction applications, commercial components are available to help developers build these applications. Many of these commercial components conform to the Distributed Transaction Processing (DTP) reference architecture [OpenGroup 96] shown in Figure 8-9, which was developed by X/Open. ^[2] In reality, not all commercial solutions follow the architecture described here. The architecture described is simply intended to provide a basic understanding of some of the commercial solutions available.

^[2] X/Open merged with the Open Software Foundation in 1996 to form the Open Group. The X/Open DTP reference architecture is more correctly referred to as the Open Group DTP reference architecture. However, we use the more commonly recognized name throughout this book.

Figure 8-9. Distributed transaction architecture

In the X/Open architecture, an application interacts with the transaction manager, resource manager, and communication resource manager through a set of transaction APIs that transparently support either local or distributed transactions. The functionality provided by each of these components is discussed in the following sections.

Resource Manager Component

A resource manager provides access to shared resources, such as database servers and file servers. Additionally, it notifies the transaction manager of resources that will be used in transactions and participates in the commit and rollback procedures that the transaction manager controls. Communication with the resource manager is achieved through two sets of APIs: the transaction manager interfaceXA (extended architecture) APIand an application component interfaceRM (resource manager) API.

The transaction manager uses the XA API to communicate with the resource manager during commit and rollback procedures and to receive resource registrations. Additionally, it provides a two-phase commit capability.

Application components manipulate data by using the RM API. The format of the RM interface is resource-manager specific and is usually an SQL interface for database resource managers. It is not uncommon for an application program to communicate with more than one resource manager.

Communication Resource Manager Component

The communication resource manager provides distributed-communications services for the local transaction manager and application. Through the XATMI (extended architecture transaction manager interface) API, applications can communicate across system boundaries, using either a peer-to-peer or an RPC communication model.

For distributed transactions, the local transaction manager uses the communication resource manager XA+ APIan expanded version of the XA APIto communicate with transaction managers on other systems. Usually, this is done to coordinate activities, such as two-phase commits.

Transaction Manager Component

The transaction manager also called a transaction processing monitor, or TP monitorcoordinates the transactions for a distributed application. The TP monitor initiates transactions for applications, tracking all the resources participating in a transaction, establishing and propagating a transaction context, and conducting the two-phase commit and rollback procedures. The transaction manager coordinates with resource managers to ensure that all the subtransactions that make up the distributed transaction are committed or rolled back together. Thus, the transaction manager provides ACID properties to a distributed transaction without the use of any specialized code in the application components.

Applications communicate with the transaction manger through a transaction manager API called the TX (transaction) API. This API consists of approximately ten primitives that allow applications to inform it of a transaction's start, end, and disposition.

Application Components

Application components implement transactions. The application component communicates with the transaction manager to start, commit, or roll back a transaction. To manipulate data, the application component communicates with the resource manager. Applications can communicate with another system's applications through the communication resource manager.

When it needs to perform a transaction, an application starts it by using the TX API. Then the application uses the RM API to update any local databases and, possibly, the XATMI API to call various remote applications to update their local databases. Next, the application uses the TX API to commit the transaction. This action causes the local transaction manager to contact all remote transaction managers via the communication resource manager, using the XA+ API, for approval to commit the transaction. Finally, if all transaction managers approve the transaction, all the database updates are made permanent; otherwise , the databases are returned to their original states before the transaction occurred.

Queued-Transaction Model

The word transactions in the term queued transactions does not refer to database transactions. In this model, transaction requestsin this case, messagesare not dispatched for immediate processing as with the distributed-transaction model. Instead, the transaction requests are put in a transactional queue for processing by a server. Transactional queues are essentially message queues with the following enhancements.

• Messages are sent within the scope of a particular transaction.

• Messages sent to the same queue are delivered in the order in which they were sent.

• Support is included for transactional operations.

Once the server processes a transactional message, the result is written to a persistent queuea response queuefor the application to retrieve. An example of this interaction is shown in Figure 8-10.

Figure 8-10. Queued-transaction model

Message queuing and queued transactions guarantee that no messages will be lost. As a result, the server does not need to be available at the time of the request; it can process requests later.

This model is quite different from the distributed-transaction model discussed earlier. In the queued-transaction model, messages are sent and received in a transaction context and placed in the transactional queue. This transaction context relates only to the message, not to a database operation. However, this context can be programatically associated with the transaction context of a database operation. The transaction context for database operations may be included in the message content.

Figure 8-11 illustrates queued transactions. In this example, the following operations occur:

1. The client starts transaction T1 and queues the request within the context of the message transaction. The queued request is not available to the server until transaction T1 is committed.

2. Next, the queue manager notifies the server of a pending request.

3. The server starts transaction T2, dequeues the request, and begins processing it. After the request is processed , the server sends a response back to the client and then finally commits transaction T2. If T2 is not committed, message M1 is not removed from the request queue, and message M2 is never placed in the response queue.

4. Next, the queue manager notifies the client of a pending response.

5. The client then starts transaction T3, dequeues the response, and begins processing it. After the response is processed, the client application commits transaction T3. If it is not committed, message M2 is not removed from the response queue.

Figure 8-11. Queued-transaction example

This model has the benefit of decoupling the client and the server, but this benefit comes at a price. Each message exchangeapplication request to server and the server responseresults in three separate message transactions, each with its own ACID properties. Therefore, it is impossible to wrap a multirequest database transaction in a single unit. Thus, under certain circumstances, it may be necessary to write a considerable amount of complex code to deal with rollbacks and other error states.

To illustrate this issue, suppose that operation 5 in the example fails. In this case, the system may want to roll back the server operations but cannot, because the server transactions are already committed. As stated earlier, this difficulty exists with queued transactions because there is no easy way to perform any type of nested or multirequest database transaction using transactional messages.

If the operations involve only one database, this problem can be solved easily by using a transaction context, as described in Section 8.3. Otherwise, resolving this problem may require complex logic to perform rollback processing, because the example violates the ACID property of isolation. The isolation problem of a multitransaction work flow usually requires application-specific solutions [Bernstein 97]. Extra processing, such as a compensating transaction or a saga, must be developed to perform rollback processing.

Another solution may be to use a transaction manager to manage the context of the global transaction. However, using such a manager may limit or eliminate the benefits of a queued-transaction model because of blocking. Note that in some cases, a rollback may not even be possible to implement without using a transaction manager.

The only other solution is to investigate changing the business logic so that a rollback is possible. This solution, however, requires reevaluating the business rules for the system.