Two-Phase Commit Protocol

As previously mentioned, distributed transactions follow a two-phase commit protocol. TimesTen Scaleout implements the two-phase commit protocol as follows:

Note:

Ensure that you understand the concepts covered in Transaction Manager and Durability Settings before reading this topic.

Phase 0: Transaction

1. An application establishes a connection to a database. Every connection is associated with a specific element of the database, which becomes the transaction manager for all distributed transactions initiated from that connection.

2. The application runs one or more SQL statements. The transaction manager sends the statements to all the participants for execution. Based on the returned results of the execution of the SQL statement, the transaction manager identifies and updates the status of the participants.

3. The application issues a commit.

Phase 1: Prepare Phase

1. The transaction manager sends a prepare message to all participants. The message includes the identity of the transaction manager and all the participants.

2. Each participant, once it receives the prepare message, performs either of these actions:

   • If the participant is a write participant, it writes a prepare-to-commit log record that stores information to subsequently either commit or rollback the transaction. The participant also locks the modified rows to prevent read operations.

   • If the participant is a read participant, it identifies the transaction as read-only.

3. The participant sends a prepare response to the transaction manager with its vote for the commit decision:

   • A write participant only votes 'Yes' if it was able to write the prepare-to-commit log record.

     Note:

     If Durability is set to 1, the participant writes a durable prepare-to-commit log record.

   • A read participant always votes 'Yes' and commits the transaction without waiting for the commit decision. In this case, the commit operation consists on releasing all locks and temporary resources related to the transaction.

Phase 2: Commit Phase

1. Once the transaction manager receives the prepare response from at least one element in every replica set participating in the transaction, it writes a prepare-to-commit log record that includes the commit decision. The transaction manager bases the commit decision on the scenarios described in Table 6-2.

   Table 6-2 Scenarios for Commit Decision

   Scenarios	Decision
   All write participants send a 'Yes' vote in their prepare response and within them there is at least one element for each participating replica set. (Failed participants do not affect the commit decision once they are identified as failed as long as its replica sends a response.)	Commit
   Any write participant sends a 'No' vote in their prepare response.	Roll back

2. The transaction manager sends a message to all write participants with the commit decision.

3. All write participants, including the transaction manager, commit or rollback the transaction based on the commit decision.

Figure 6-1 shows the two-phase commit protocol as implemented for distributed transactions in TimesTen Scaleout.

Figure 6-1 Two-Phase Commit Protocol

Description of "Figure 6-1 Two-Phase Commit Protocol"

Two-Phase Commit Failure Analysis

There are several types of potential failures that may affect the operation of a database for outstanding distributed transactions. Table 6-3 summarizes these failure types and describes how TimesTen Scaleout responds to them.

Table 6-3 Failure Types in a Distributed Transaction

Failure	Action
Transaction manager fails.	If the transaction manager fails (for example, the application terminates), the main daemon for that instance catches the failure and informs the subdaemon. The subdaemon sends a commit or rollback message to all participants depending on the state of the transaction.
The host of the transaction manager fails.	If the host of the transaction manager fails, the daemon and all subdaemons fail. Each participant will recognize this failure when their TCP connection to the transaction manager closes or times out. Once a participant recognizes the failure, the participant rolls back any transaction that has not reached the prepare phase. If the participant already sent its prepare response, it will ask other participants for the commit decision and perform one of the following actions: If at least one of the other participants received the commit decision, then the asking participant will fulfill the commit decision. If none of the other participants received the commit decision, then the asking participant waits for the transaction manager to recover.
All elements from a participating replica set fail before writing a prepare-to-commit log record.	The transaction manager decides to rollback the transaction.
Participant fails after writing a prepare-to-commit log record.	The participant, once it recovers, requests the commit decision from one of the other participants.
Participant is busy.	The transaction manager waits until it receives a prepare response from the participant.