Transaction Management:

- A series of steps in a flow must succeed or fail as one unit.

- Mule uses a transaction to define such a unit.

For example, you might use a transaction to encapsulate several steps in a flow for which
the end result involves committing information to a database. In this type of scenario, the
commit is either entirely complete and succeeds, or is incomplete and it fails. Even if
partially complete, the commit – or transaction – fails. Where a transaction fails, Mule rolls
back the operations within the transaction so that no one part results in partial completion.

- You can define a transaction by applying a transaction to a connector.

- If a Mule flow begins with a transactional resource (such as an inbound connector), Mule
can start a new transaction and manage the entire flow as a transaction.
- If your flow includes a transactional outbound connector, Mule manages the outgoing
operation as a transaction. With both a transactional inbound and outbound connector,
Mule executes the outgoing operation as part of the transaction initiated by the inbound
connector.

The following connectors support transactional demarcation

JMS
Database
VM
A Mule flow may begin with a non-transactional inbound connector – such as HTTP or SFTP –
but which requires the use of a transaction within the flow.
For example, a Mule flow may accept information from an external Web service, then
transform the data, before charging a credit card, and saving invoice information to a database.
In such a situation, you can define a transaction by wrapping the credit card charge and
database commit operations within a transaction to ensure either complete success or
complete failure and rollback

Mule supports 3 different types of transactions:

1. single resource
2. multiple resource
3. extended architecture (XA).
Type Characteristics No, Of Available Performance
Resources resources
Single Resource Receives or sends 1 1. JMS Relative to the others,
Transactions messages to only one 2. VM Performs better
resource 3. Database
Multiple Resource Receives or sends >1 1. JMS Performs better than
Transactions messages to more than 2. VM XA, though slower
one resource 3. Database than Single Resource

Can handle partial With 1.5PC, functions

commits and rollbacks less reliably than XA

Uses 1.5 commit protocol

as opposed to two-phase
commit protocol
XA Transactions Receives or sends >1 1. JMS Relative to the others,
messages to more than 2. VM performs slower but
one resource 3. Database more reliably

Involves using an two-

phase commit algorithm.
Connectors must be XA-
enabled.

Configuring Transactions
You can demarcate a transaction by either applying a transactional configuration to a
connector, or by wrapping several elements in a transactional scope.

1. Apply a transaction to an inbound connector when you want Mule to handle the
complete flow as a transaction.

2. Apply a transaction to an outbound connector when you want Mule to handle the
outgoing operation as part of an existing transaction.

3. Apply a transaction as a wrapper (known as a scope in Studio) when you want to

apply a transaction to elements within a flow that do not begin with a inbound
connector configured as a transaction.
Single Resource Transaction:
We will single Resource Transaction to send or receive messages using only one resource: JMS,
VM or Database.
Use Case-
Let us consider an example where we want to insert a Customer and his Order details into two
Oracle tables named CUSTOMER and CUSTOMER_ORDER respectively.
CUSTOMER table
CREATE TABLE CUSTOMER (
CUSTOMER_ID INT AUTO_INCREMENT,
NAME VARCHAR(255),
ADDRESS VARCHAR(255),
CONSTRAINT PK_CUSTOMER_ID PRIMARY KEY(CUSTOMER_ID)
)

CUSTOMER_ORDER table
CREATE TABLE CUSTOMER_ORDER (
ORDER_ID INT AUTO_INCREMENT,
ITEM VARCHAR(255) NOT NULL,
SHIPPING_ADDRESS VARCHAR(255) NOT NULL,
CUSTOMER_ID INT,
CONSTRAINT PK_ORDER_ID PRIMARY KEY(ORDER_ID),
CONSTRAINT FK_ORDER FOREIGN KEY(CUSTOMER_ID) REFERENCES
CUSTOMER(CUSTOMER_ID)
)

Note: Create these tables with PK, FK relationships

Case 1- Pass all fields data from inbound connector.
Once get the data it will insert into customer (1st table) and then insert into 2nd table so that
data will sit into 2 tables.
Case 2- Pass all fields data from inbound connector one mandatory field for 2 nd table.
Once get the data it will insert into customer (1st table) and then try to insert into 2nd table but
due to constraints database will reject/fail. so 1st table inserted data also will roll back due
transactional scope.
Example Flow: