Distributed transactions and the two-phase commit protocol

A distributed transaction is one that runs in multiple processes or one that involves multiple physical database connections. Each process participates in the transaction. This is illustrated in the following diagram, where each oval indicates work being done on a different server, and each arrow indicates a remote method invocation (RMI):

Distributed transactions, like local transactions, must adhere to the properties of atomicity, consistency, isolation, and durability. However, maintaining these properties is greatly complicated for distributed transactions because a failure can occur in any process, and in the event of such a failure, each process must undo any work already done on behalf of the transaction.

A distributed transaction processing system maintains these properties in distributed transactions by using these features:

• Recoverable processes
  Recoverable processes are those that can restore earlier states if a failure occurs.

• A commit protocol
  A commit protocol enables multiple processes to coordinate the committing or rolling back (canceling) of a transaction. The most common commit protocol, and the one used by the WAS, is the two-phase commit protocol.

Transaction state information must be stored by all recoverable processes. However, only processes that manage application data (such as resource managers) must store descriptions of changes to data. Not all processes involved in a distributed transaction need to be recoverable. In general, clients are not recoverable because they do not interact directly with a resource manager. Processes that are not recoverable are referred to as ephemeral processes.

The two-phase commit protocol

Distributed transactions use a two-phase commit protocol to synchronize related pieces of work that take place in different processes or on different database servers.

The protocol guarantees that the work is either successfully completed by all the processes or not performed at all. The modifications to data are all committed together or rolled back together. The goal is to ensure that each participant in a transaction takes the same action (both are committed or both are rolled back). During the lifetime of a transaction, any participant in the transaction can unilaterally decide to discontinue the transaction.

The two-phase commit protocol, as the name implies, involves two phases: a prepare phase and a resolution phase. In each transaction, one process acts as the coordinator. The coordinator oversees the activities of the other participants in the transaction to ensure a consistent outcome.

After all of the work of the transaction is complete, the application attempts to commit the work by invoking the two-phase commit protocol.

These are the two phases in the two-phase commit protocol:

1. Prepare phase
   In the prepare phase, the coordinator sends a message to each process in the transaction, asking each process to prepare to commit. When a process prepares, it guarantees that it can commit the transaction and makes a permanent record of its work. After guaranteeing that it can commit, it can no longer unilaterally decide to roll back the transaction. If a process cannot prepare (that is, if it cannot guarantee that it can commit the transaction), it must roll back the transaction.

2. Resolution phase
   In the resolution phase, the coordinator tallies the responses. If all participants are prepared to commit, the transaction commits; otherwise, the transaction is rolled back. In either case, the coordinator informs all participants of the result. In the case of a commit, the participants acknowledge that they have committed.

The implementation of the two-phase commit protocol in WAS requires the use of transaction log files. For more information, see Transaction log files.