1. Scaleout User's Guide
  2. Understanding Distributed Transactions in TimesTen Scaleout
  3. Transaction Manager

Transaction Manager

Applications connect to a database in TimesTen Scaleout by connecting to one element of the database. Each transaction ran by a connection requires a transaction manager. For client/server applications the transaction manager is the thread in the TimesTen Scaleout server that is acting as a proxy for the application. For direct mode applications the transaction manager is the thread in the application that connects to TimesTen Scaleout. The transaction manager coordinates the execution of statements on elements (participants), or more specifically:

  • If the application issues a commit or rollback, the transaction manager ensures that all participants have consistent data based on the commit or rollback decision from the two-phase commit protocol.

  • If a participant returns an error, such as a constraint violation, the transaction manager coordinates the response. The transaction manager ensures that TimesTen Scaleout returns the appropriate error message to the user and that all participants release the allotted resources.

  • If a participant fails, the transaction manager creates a state that the failed participant uses during its recovery to restore to a consistent state.

  • If the participant where the transaction manager resides fails, participants classify the transaction as in-doubt if they completed the prepare phase but did not receive the commit decision and are no longer able to reach the transaction manager.

Status of the Participants

When a participant completes the execution of a statement, it sends a message to the transaction manager. The message includes information about the number of rows affected. If the message specifies that:

  • The participant modified the affected rows, such as with a INSERT, UPDATE, or DELETE operation, the transaction manager flags the participant as a write participant.

  • The participant did not modify any rows, then the transaction manager flags the participant as a read participant.

The read or write status of a participant affects the way the transaction manager processes a commit operation:

  • If all participants are read participants, then the transaction manager handles the commit without going through the prepare phase. In other words, read participants perform the commit operation without needing a consensus from the other participants.

  • If there are one or more write participants, then the transaction manager handles the commit as a two-phase operation.