XA Transactions
Use an XA transaction to group together a series of operations from multiple JMS, VM or JDBC resources into a single, very reliable, virtual transaction.
The following example illustrates a flow in which two endpoints use XA transaction to function as a single transactional unit.
<flow name="JmsToJdbc">
<jms:inbound-endpoint queue="my.queue" reuseSession="false"/>
<xa-transaction action="ALWAYS_BEGIN" timeout="60000"/>
</jms:inbound-endpoint>
<jdbc:outbound-endpoint address="writeTest" type="2">
<xa-transaction action="ALWAYS_JOIN"/>
</jdbc:outbound-endpoint>
</flow>Beyond the code displayed above, this configuration must use transports which support XA transactions. Specifically, this example uses a JMS connector which employs a JMS XA Connection Factory, and a JDBC connector which uses an XA-enabled data source.
As with a multiple resource transaction, if you configure an inbound endpoint with an XA transaction, you must also configure any other endpoints as XA transactions and set the action to "ALWAYS_JOIN" to become part of the virtual transaction unit. XA transactions employ the concept of suspend/resume. If you configure one flow to use an XA transaction set to ALWAYS_BEGIN, and then Mule forwards the message to another flow with an XA transaction set to ALWAYS_BEGIN, Mule suspends the first transaction until the second transaction completes.
Setting the Polling Frequency
When you configure an inbound JMS endpoint with XA transactions, the receiver polls every 100 ms. You can change the polling frequency by adjusting the pollingFrequency property. The following example illustrates how to set the polling frequency.
<jms:inbound-endpoint queue="my.queue" reuseSession="false">
<xa-transaction action="ALWAYS_BEGIN" timeout="60000"/>
<properties>
<spring:entry key="pollingFrequency" value="5000"/>
</properties>
</jms:inbound-endpoint>This property is only applicable if you are using the the default transport, XaTransactedJmsMessageReceiver , on JMS inbound endpoints configured to use XA transactions. If you are using JBoss transactions, please read JBoss Transaction Manager Reference to learn how to configure the timeout value.
Mule Transaction Manager
Though you demarcate transactions based on endpoints (i.e. resources) and wrappers, Mule actually manages transactions using the Mule Transaction Manager. The Transaction Manager is a singleton manager which governs all the transactions in a Mule instance. It provides methods for binding and unbinding transactions and is responsible for retrieving the current transaction state.
Mule uses javax.transaction.TransactionManager to manage XA transactions with multiple resources. If you intend to use the SUSPEND semantics for your transactions, you must use this transaction manager. However, depending on your application server vendor, you may have access to other transaction manager options. The table below summarizes the transactions managers available on common application servers.
| Application Server | Remote | Embedded | Common Location | Lookup class |
|---|---|---|---|---|
JBoss |
|
java:/TransactionManager |
|
|
JRun |
|
java:/TransactionManager |
|
|
Other |
|
Specified via a |
|
|
Resin |
|
java:comp/TransactionManager |
|
|
WebLogic |
|
|
javax.transaction.TransactionManager |
|
WebSphere |
|
proprietary API call |
|
|
XA transactions for Weblogic are not supported in Mule ESB Standalone. Use Mule in embedded mode in order to use XA transactions for Weblogic. |
To configure your Mule application to use a specific transaction manager, configure the custom-transaction-manager as per the example below.
<custom-transaction-manager class="org.mule.transaction.lookup.WeblogicTransactionManagerLookupFactory" />Refer to Transaction Management for details on how to configure an XA transaction.