Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.6)
  3. Developing
  4. Transaction Management

  5. Multiple Resource Transactions

Multiple Resource Transactions

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.

Use a Multi Resource transaction to group a series of operations from multiple JMS or VM resources into a single virtual transaction.

Multiple resource transactions are useful for creating transactional bridges without employing distributed transactions. For example, if you want to bridge two different connectors to form a transactional unit you could configure the multiple resource transaction as per the example below:

<mule xmlns:wmq="http://www.mulesoft.org/schema/mule/ee/wmq" xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xmlns:jms="http://www.mulesoft.org/schema/mule/jms" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd

http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd

http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd

http://www.mulesoft.org/schema/mule/ee/wmq http://www.mulesoft.org/schema/mule/ee/wmq/current/mule-wmq-ee.xsd

http://www.mulesoft.org/schema/mule/jms http://www.mulesoft.org/schema/mule/jms/current/mule-jms.xsd">

    <jms:activemq-connector name="jmsConnector"
                            maxRedelivery="3"
                            disableTemporaryReplyToDestinations="true"/>

    <wmq:connector name="wmqConnector"
                   hostName="winter"
                   port="1414"
                   disableReplyToHandler="true"
                   disableTemporaryReplyToDestinations="true"
                   queueManager="MY_QUEUE_MANAGER"
                   targetClient="NONJMS_MQ"
                   transportType="CLIENT_MQ_TCPIP"
                   specification="1.1"
                   numberOfConsumers="16"
                   username=""
                   password=""/>

    <flow name="MultiTxFlow">
        <jms:inbound-endpoint queue="in" connector-ref="jmsConnector">
            <ee:multi-transaction action="ALWAYS_BEGIN"/>
        </jms:inbound-endpoint>
        <test:component/>
        <wmq:outbound-endpoint queue="out" connector-ref="wmqConnector">
             <ee:multi-transaction action="ALWAYS_JOIN"/>
        </wmq:outbound-endpoint>
    </flow>
</mule>

In this example, Mule starts the local JMS transaction when it receives the message on the inbound endpoint. Mule starts the local WMQ transaction when it sends the message out on the outbound endpoint. In this case, because the connectors are configured as multiple resource transactions, Mule commits the WMQ transaction first, then commits the JMS transaction.
Ultimately, Mule either commits both transactions successfully or fails and rolls back both of them as one virtual unit.

Consider that grouping connector operations into one multiple resource transaction implies a tradeoff between low overhead and reliability.
Although multiple resource transactions are intended to have less overhead than XA transactions, under certain circumstances (e.g. one of the brokers crashing while commit/rollbacks are performed), an unacknowledged message could be redelivered later, causing duplicate data processing if not handled properly. You might even have to handle these duplicates manually.
If reliability is your main concern, you should always use XA transactions.

Note that if you configure an inbound connector with a multiple resource transaction, you must also configure any other connectors as multiple resource transactions and the action set to "ALWAYS_JOIN" to become part of the virtual transaction unit.

Refer to Transaction Management for details on how to configure a Multiple Resource transaction.