Transaction Management in Mule

Author: Rutik Ambre

Introduction 

Transactions are operations in a Mule app for which the result cannot remain indeterminate. The transaction comprises a group of activities. Suppose you have a requirement of performing a group of activities and execute all at once, and even if one fails, you have to roll back. So in this scenario, you can use transactions in mule. 

Transaction Types

Mule supports Single Resource (Local, the default) and Extended Architecture (XA) transaction types (transaction type). The only components that can define the transaction type are message sources (For example, jms:listener and vm:listener) and the Try scope.

Local	Extended Architecture
Performs better than XA, but it is less reliable.	Slower than Local but more reliable.
All operations inside the transaction must belong to the same Connector.	Operations can belong to the same as well different connectors.

• Transactional Actions

• Always Begin – Always start a new transaction when receiving a message. If a Single Resource transaction exists, an error occurs. If an XA transaction exists, a nested transaction is created.
• Begin or Join – Join a transaction if it exists or else start a new transaction.
• Always Join – Always expects a transaction to be in progress.
• Indifferent – Do not treat it as a transaction.
• None – Do not start a transaction.
• Not Supported – Execute outside any existent transaction.
• Join If Possible – Join if a transaction is available or else do nothing.

• Prerequisites

• Anypoint Studio (7.5 and above)
• Mule Runtime (4.3.0 and above)

Demo

There are two ways to configure a transaction: you configure the transaction in the message source (in this case, your entire flow will become a transaction), or you configure the transaction in the try scope. In this demo, we will configure transactions in a try scope. 

In this example, we will try to insert data into 2 tables, one after the other, within the same flow. 

Here we will check 2 scenarios. 

1. When both the insert operations are successful, in this case data will be inserted into both the tables.
2. When the first Insert is successful and the second insert fails, in this case the first one will be rolled back.

Table Schema

Flow

Note: Execute Script contains begin and commit, which is needed in the case of remote MySQL to treat the transaction as a single block. It will work even if you don’t add the execute script components for other databases. Even for these “Execute Script” components, select transaction action to “Always Join” in the advanced section. 

Configuration to be made in the flow

1. In the try block select Transaction Action to “Always_Begin” and Type to “Local”

2. In the advanced section of DB Insert for Table1 select Transaction Action to “Always Join”

3. In the advanced section of DB Insert for Table2, select Transaction Action to “Always Join”

• Scenario1

Both the Insert Operations are Successful. 

Result: Data inserted in both the tables.

• Input: 

• Output:

• Scenario2

The first is Successful, and the second is Unsuccessful.

Result: Data not inserted in both the tables.

• Input:

• Output:

No Data Inserted in Either of the Tables even if the first one was successful as the failure of the second insertion led to a rollback of the entire transaction.

Hence we have successfully implemented transaction management in Mule4.