This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.
Transactions
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, namely Financial transactions, Database transactions, etc. In the ESB point of view, there are two types of transactions:
Distributed Transaction
A distributed transaction is a transaction that updates data on two or more networked computer systems. It extends the benefits of transactions to applications that must update distributed data. 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 section JMS Transactions.
Transaction Mediator
A new synapse mediator ( Transaction Mediator ) has been added to support the distributed transactions using Java transaction API(JTA). JTA allows applications to perform a distributed transaction that is, transactions that access and update data on two or more networked computer resources (an example would be to have two databases or a database and a message queue such as JMS). This mediator can be used to perform a distributed transaction. The synapse configuration has been extended to add explicit transaction markers. What this means is you can use the synapse configuration language 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 meanings:
Value | Meaning |
---|---|
new | Creates a new JTA transaction. Generates a fault if a transaction already exist. |
use-existing-or-new | Creates a new JTA transaction. Does nothing if a transaction exists. |
fault-if-no-tx | Generates a fault if no transaction exist. Does nothing if a transaction exists. |
commit | Commits transaction. Generates a fault if no transaction exists. |
rollback | Rollbacks transaction. Generates a fault if no transaction exists. |
suspend | Suspends transaction. Generates a fault if no transaction exists. |
resume | Resumes transaction. Generates a fault if no transaction exists. |