Show TOC

Distributed TransactionsLocate this document in the navigation structure

Use

Distributed transactions work with more than one resource manager and must synchronize their tasks, or transaction branches, when they finish their work. This typically happens when an application needs to request updates to several different databases. The Transaction Manager coordinates the recoverable units of work of the Resource Managers that are part of this transaction.

The two-phase commit (2PC) protocol ensures the atomicity of distributed transactions. This means that there is one coordinator branch that sends a request to all other branches of the transaction to prepare the commit. The coordinator is the server process that starts the distributed transaction. The 2PC protocol consists of two phases. During the first one, all transaction branches are prepared to be committed with the prepare() method. This preparation phase guarantees that the Resource Managers are able to commit the transaction branches. In the second phase the actual commit or rollback is executed.

The possible states of distributed transactions are:

  • ACTIVE - the distributed transaction is currently active, messages are being produced and consumed.

  • IDLE - the transaction has been started but there are no activities under it at the moment.

  • SUSPENDED - the transaction has been suspended but there are no activities under it at the moment.

  • PREPARED - the prepare() method has been called. The information is persisted in database.

  • ROLLBACK_ONLY - active timeout has occurred. The transaction can only be rolled back.

  • HEUR_COMMITTED - transaction has expired.

  • HEUR_ROLLEDBACK - transaction has expired.

Figure 1: Distributed Transaction States

The INITIAL state is the state where the transaction still does not exist. When a transaction is started it enters the ACTIVE state. At the end of its life cycle, after a commit or rollback, the transaction enters again the INITIAL state.