This documentation is for WSO2 Enterprise Service Bus version 4.7.0 . View documentation for the latest release.
Skip to end of metadata
Go to start of metadata

A transaction is a set of operations executed as a single unit. It also can be defined as an agreement, which is carried out between separate entities or objects. A transaction can be considered as indivisible or atomic when it has the characteristic of either being completed in its entirety or not at all. During the event of a failure for a transaction update, atomic transaction type guarantees transaction integrity such that any partial updates are rolled back automatically.

Transactions have many different forms, such as financial transactions, database transactions, etc. From the ESB point of view, there are two types of transactions: distributed and JMS.

Distributed Transaction

A distributed transaction is a transaction that updates data on two or more networked computer systems, such as two databases or a database and a message queue such as JMS. Implementing robust distributed applications is difficult because these applications are subject to multiple failures, including failure of the client, the server, and the network connection between the client and server. For distributed transactions, each computer has a local transaction manager. When a transaction works at multiple computers, the transaction managers interact with other transaction managers via either a superior or subordinate relationship. These relationships are relevant only for a particular transaction.

Java Message Service (JMS) Transactions

In addition to the distributed transactions, WSO2 ESB also has support for JMS transactions. The JMS transport shipped with WSO2 ESB has support for both local and distributed transactions.

Read more information about JMS transactions and configuration in JMS Transactions.

Transaction Mediator

The Transaction Mediator supports distributed transactions using the Java transaction API (JTA). You can configure the mediator to define the start, end etc. of your transaction. It is the responsibility of the user to define when to start, commit or rollback the transaction. For example, you can mark the start of a transaction at the start of a database commit and end of the transaction at the end of the database commit and you can mark rollback transaction if a failure occurs.

Transaction Mediator Configuration
<transaction action="new|use-existing-or-new|fault-if-no-tx|commit|rollback|suspend|resume"/>

The action attribute has the following options:




Creates a new JTA transaction. Generates a fault if a transaction already exist.


Creates a new JTA transaction. Does nothing if a transaction exists.


Generates a fault if no transaction exist. Does nothing if a transaction exists.


Commits transaction. Generates a fault if no transaction exists.


Rollbacks transaction. Generates a fault if no transaction exists.


Suspends transaction. Generates a fault if no transaction exists.


Resumes transaction. Generates a fault if no transaction exists.

For examples of using transactions, see Transaction Examples.

  • No labels