Nav

Transaction Management

Transactions are operations in a Mule app for which the result cannot remain indeterminate. When a series of steps in a flow must succeed or fail as one unit, Mule uses a transaction to demarcate that a unit. For example, you might use a transaction to encapsulate several steps in a flow that result in committing information to a database. In this type of scenario, the commit (or transaction) is either entirely complete and succeeds, or is incomplete and fails. Even if partially complete, the commit fails. When a transaction fails, Mule rolls back the operations within the transaction so that no one part results in partial completion.

The Try scope provides a way to configure a transaction from its General tab. The XML for this configuration looks like this:

XML Example: Transaction Configuration in the Try Scope

In this example, the Try scope demarcates a transaction that includes a database operation and a VM operation. Either both will be applied, or none will be applied if an error is raised within the Try scope.


         
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:vm="http://www.mulesoft.org/schema/mule/vm" xmlns:db="http://www.mulesoft.org/schema/mule/db"
        xmlns="http://www.mulesoft.org/schema/mule/core"
        xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd
http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/current/mule-vm.xsd">
        <db:config name="Database_Config">
                <db:derby-connection database="myDb" create="true" />
        </db:config>
        <vm:config name="VM_Config">
                <vm:queues>
                        <vm:queue queueName="myQueue" />
                </vm:queues>
        </vm:config>
        <flow name="transactionsFlow">
                <try transactionalAction="ALWAYS_BEGIN" transactionType="XA">
                    <db:insert doc:name="Insert" transactionalAction="ALWAYS_JOIN">
                          <db:sql>
                                  INSERT INTO main_flow_audit (errorType, description) VALUES (:errorType, :description)
                          </db:sql>
                          <db:input-parameters><![CDATA[
                             #[{
                                 'errorType' : 'AUTHENTICATION',
                                 'description' : 'invalid authentication credentials',
                              }]
                    ]]></db:input-parameters>
                     </db:insert>
                     <vm:publish config-ref="VM_Config" queueName="myQueue" transactionalAction="ALWAYS_JOIN"/>
                </try>
        </flow>
</mule>

It’s also possible to start a transaction from a message source. In that case, the entire flow is a transaction. This is useful when working with messaging connectors to prevent the consumption of the message if a problem occurs when processing it so you can later retry (because of the rollback).

XML Example: Transaction Configuration in the Message Source

         
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:vm="http://www.mulesoft.org/schema/mule/vm"
        xmlns="http://www.mulesoft.org/schema/mule/core"
        xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/current/mule-vm.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">

        <vm:config name="VM_Config1" >
                <vm:queues >
                        <vm:queue queueName="input" />
                        <vm:queue queueName="output" />
                </vm:queues>
        </vm:config>

        <flow name="source-transactionsFlow">
                <vm:listener config-ref="VM_Config1" queueName="input" transactionalAction="ALWAYS_BEGIN"/>
                <http:request method="GET" url="www.google.com"/>
                <vm:publish config-ref="VM_Config1" queueName="output"/>
        </flow>
</mule>

In Studio, operations in these connectors provide an Advanced tab for setting up transactions:

  • JMS:

    • Listener supports Local and XA transaction types. When set, the entire flow is treated as a transaction.

    • Consume and Publish operations support transactions.

  • VM:

    • Listener supports Local and XA transaction types. When set, the entire flow is treated as a transaction.

    • Consume and Publish operations support transactions.

  • Database:

    • All database operations support transactions.

Note that a Mule flow can begin with a non-transactional connector (such as HTTP) that requires a transaction within the flow. For example, a Mule flow might 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 might use the Try scope to set up 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.

Transactional Actions

A Transactional Action (transactionalAction)

  • ALWAYS_BEGIN: Always start a new transaction when receiving a message. An exception will be thrown if a transaction already exists. Listeners that support transactions have this option.

  • ALWAYS_JOIN: Always expect a transaction to be in progress when a message is received. If there is no transaction, an exception is thrown. Operations that support transactions have this option.

  • BEGIN_OR_JOIN: If a transaction is already in progress when a message is received, join the transaction if possible. Otherwise, start a new transaction. Scopes that support transactions provide this setting.

  • JOIN_IF_POSSIBLE: Join the current transaction if one is available. Otherwise, no transaction is created. Operations that support transactions provide this setting.

  • INDIFFERENT: Do not treat actions as a transaction. Scopes that support transactions provide this setting.

  • NONE: Never participate in a transaction. Listeners that support transactions provide this setting.

  • NOT_SUPPORTED: Execute outside any existent transaction. Operations that support transactions provide this setting. Scopes that support transactions provide this setting.

Transaction Types

Mule supports Single Resource (Local, the default) and Extended Architecture (XA) transaction types (transactionType). The following table describes characteristics of each type.

  • Single Resource Transactions (Local)

    • Receives or sends messages to only one resource.

    • Performs better than XA.

  • XA Transactions

    • Receives or sends messages to more than one resource.

    • Involves using a two-phase commit algorithm. 

    • Connectors must be XA-enabled.

    • Slower but more reliable than Local.

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.

+