Transactions in Mule

"To err is human; to forgive, divine"

But customers tend not to be so forgiving when you mess up their tasks. Integration is a vast thing and there are many things that can go wrong. While it is possible to manage unexpected situations by appropriate exception handling mechanisms, we do know that if an error occurs we also need to restore the system to a state of consistency. This is where the concept of Transactions come into the equation.

A transaction is a unit of interaction that guarantees the integrity or consistency of a data source. This source can be either a queue as in a JMS transaction, or it can be a database like a JDBC transaction.

A transaction is said to be atomic. It is considered as a series of indivisible operations that will either succeed or fail as a single unit. If any step fails in a transaction then the entire transaction must be rolled back to leave the data source as it was. If there are no errors all changes should be committed. The key to this is knowing the boundaries of the transaction, where it starts where it ends and what steps should be encapsulated in the transaction.

Mule supports three different types of transactions:-

• Single Resource Transaction  
• Multiple Resource Transaction
• XA Transactions

Single Resource Transactions

As the name suggests, in a single resource transaction there is only one resource involved with receiving or sending messages. Mule supports single resource transactions thus natively supporting JDBC and JMS transactions. Even the VM transport has support for transnationality which can be used if required. Relative to the other types this performs much faster due to the presence of just a single resource and less overhead.

Multiple Resource Transactions

Multiple Resource Transactions involve receiving or sending messages to more than one resource. When multiple resources are involved maintaining the atomicity of the transaction becomes a significant issue as the consistency of data needs to be maintained in multiple places. Atomic Commitment Protocols (ACP) are used for these cases to support the global atomicity of the transaction. Multiple Resource Transactions in Mule used 1.5 commit protocol rather than the generally suing two-phase commit protocol. Due to this though the transactions are faster than XA which uses two-phase commit but the reliability decreases.

XA Transactions

XA Transactions allows a single transaction to span across multiple resources while acting as a global atomic transaction. XA transactions use two-phase commit and is considered as the de-facto standard for distributed transaction processing. Like the ACID properties in databases XA creates a global transaction that maintains the ACID properties within it.

While XA and Multi-resource offer similar functionality, it is essentially a trade-off between reliability and speed. While XA transactions offer more reliability by using two-phase commit, Multi- resource transactions are much faster owing to the less overhead. Both the transactions can involve JDBC, JMS resources etc. but in case of XA the resources should be XA-enabled resources. The default XA transaction Manager for mule is Bitronix.

Transaction Manager

In mule though we can set the transaction boundaries by using connectors or the transaction scope, every mule application still needs a transaction manager that is responsible for controlling the transactions in it. It provides methods for binding and unbinding transactions and is responsible for retrieving the current transaction state. You can have at most one Mule Transaction Manager in a Mule application. A Mule Transaction Manager can also be shared among multiple applications by defining a manager in a domain project.

The default and recommended global XA Transaction Manager in mule is Bitronix. However, we can use any transaction manager of our choice depending on our application server vendor. Whichever global XA transaction manager is being used, the XA transactions between each XA resource is managed inside Mule flow using the standard javax.transaction.Transactionmanager interface only.

The transaction managers available on common application servers:-

1. JBoss  (org.mule.transaction.lookup.JBossTransactionManagerLookupFactory)
2. JRun (org.mule.transaction.lookup.JRunTransactionManagerLookupFactory)
3. Resin (org.mule.transaction.lookup.Resin3TransactionManagerLookupFactory)
4. Weblogic (org.mule.transaction.lookup.WeblogicTransactionManagerLookupFactory)
5. WebSphere (org.mule.transaction.lookup.WebsphereTransactionManagerLookupFactory)
6. Other (org.mule.transaction.lookup.GenericTransactionManagerLookupFactory)

      Transactional Endpoints

Database Connector 

The Database connector provides three transactional actions.

1.  ALWAYS_JOIN: This specifies that the operations should always join a transaction and assumes that one is already started. If there is no transaction then an exception is raised.
2.  JOIN_IF_POSSIBLE (Default): This is the default action for db connector. This action instructs to join a transaction if a transaction is already in progress otherwise continue normally.
3. NOT_SUPPORTED: This indicates that this connector executes outside the transactional operation. The transaction continues and does not fail due to this.

       VM Connector

       

       VM Connectors have six possible transactional actions

1. ALWAYS_BEGIN: When a message is received a new transaction is started.
2. ALWAYS_JOIN: This specifies that the operations should always join a transaction and assumes that one is already started. If there is no transaction then an exception is raised.
3. BEGIN_OR_JOIN: If a transaction is ongoing then join else create a new transaction
4. JOIN_IF_POSSIBLE: This action instructs to join a transaction if a transaction is already in progress otherwise continue normally.
5. NONE (Default): Resolves any active transaction then execute as non-transactional
6. NOT_SUPPORTED: This indicates that this connector executes outside the transactional operation. The transaction continues and does not fail due to this.

JMS Connector

JMS Connectors also have the same six transactional actions as VM connector which is described above.

So, there can be six possible transactional actions:-

• ALWAYS_BEGIN: When a message is received a new transaction is started.
• ALWAYS_JOIN: This specifies that the operations should always join a transaction and assumes that one is already started. If there is no transaction then an exception is raised.
• BEGIN_OR_JOIN: If a transaction is ongoing then join else create a new transaction
• JOIN_IF_POSSIBLE: This is the default action. This action instructs to join a transaction if a transaction is already in progress otherwise continue normally.
• NONE: Resolves any active transaction then execute as non-transactional
• NOT_SUPPORTED: This indicates that this connector executes outside the transactional operation. The transaction continues and does not fail due to this.

The NONE and NOT_SUPPORTED transactional actions might seem similar but there is a slight difference between the two.

 In case of NONE, if a transaction already exists then it is either committed or rolled back depending on its current state and if there is no active transaction then it’s a no-op. The connector then executes the operation as non-transactional.
While for NOT_SUPPORTED action it ignores any active transaction, if present and does not affect the state of any transaction. The operations in this are executed in a non-transactional manner outside the transaction which continues to execute. In short, NOT_SUPPORTED does not resolve the transaction as NONE does.