This documentation is for WSO2 Enterprise Integrator version 6.3.0 . View documentation for the latest release in the 6.x.x family and the latest release in the 7.x.x family.

All docs This doc
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

The Message Broker profile in WSO2 Enterprise Integrator (WSO2 EI) supports XA transactions (distributed transactions). That is, when a client sends a set of transactional messages (XA transactions) to the queues defined in the broker profile of WSO2 EI, if at least one transaction fails, all the transactions will be rolled back by the broker.

For example, let's take the ESB profile of WSO2 EI as the client sending the messages to the Message Broker profile. A proxy service is configured in the ESB profile to send these messages to three separate queues (mbqueue1, mbqueue2, and mbqueue3) defined in the Broker. If at least one transaction fails, all the transactions are rolled back. As explained by this example, the behavior of XA transactions is straightforward when there is a single broker node. However, if you have a clustered setup, you need to correctly configure the failover method for you XA transactions. You also need to configure the maximum number of XA transactions that can be handled by the broker.

See the following topics for details:

Configuring the maximum number of XA transactions

You can configure the maximum number of distributed transactions that can be handled in parallel by the Message Broker profile of WSO2 EI. To do this, set the following parameter in the broker.xml file (stored in the <EI_HOME>/wso2/broker/repository/conf directory).


Handling failover of XA transactions

Now, let's consider a scenario where the client (for example, the ESB profile) is sending messages to a cluster of broker nodes. In a cluster, if the connection between the client and one broker node fails, the client connects to the next available broker node in the cluster to complete the transaction. The failover method specified for the connection determines how the failover from one node to another is handled. In the case of XA transactions, be sure to use the 'onetime' failover method. If you use other failover methods, such as 'roundrobin', the XA transactions will be disrupted.

See Setting the Connection URL for instructions on how to enable the failover method for a connection.

Test distributed transactions with WSO2 EI's Message Broker

You can see how this works by following the steps given below.

  1. Follow the instructions in configuring the ESB profile with the Message Broker profile
  2. Start the Message Broker profile and create three queues: mbqueue1, mbqueue2, and mbqueue3
  3. Start the ESB profile and add a proxy service to mediate messages to the broker. To handle XA transactions, the proxy service should be configured as shown below. In this example, the ESB listens to a JMS queue named MyJMSQueue and consumes messages and sends messages to multiple JMS queues in a transactional manner.

    <?xml version="1.0" encoding="UTF-8"?>
    <proxy xmlns=""
             <property name="OUT_ONLY" value="true"/>
             <log level="custom">
                <property expression="get-property('MessageID')" name="MESSAGE_ID_A"/>
             <log level="custom">
                <property expression="$body" name="BEFORE"/>
             <property expression="get-property('MessageID')"
             <property description="FailureResultProperty"
                <result xmlns="">failure</result>
                <source clone="true" xpath="$ctx:failureResultProperty"/>
                <target type="body"/>
             <log level="custom">
                <property expression="$body" name="AFTER"/>
             <property name="BEFORE1" scope="axis2" type="STRING" value="ABCD"/>
             <callout serviceURL="jms:/MBQueue1?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&amp;java.naming.factory.initial=org.wso2.andes.jndi.PropertiesFileInitialContextFactory&amp;java.naming.provider.url=conf/;transport.jms.DestinationType=queue&amp;transport.jms.TransactionCommand=begin">
                <source type="envelope"/>
                <target xmlns:s11=""
                        xpath="s11:Body/child::*[fn:position()=1] | s12:Body/child::*[fn:position()=1]"/>
             <callout serviceURL="jms:/MBQueue2?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&amp;java.naming.factory.initial=org.wso2.andes.jndi.PropertiesFileInitialContextFactory&amp;java.naming.provider.url=conf/;transport.jms.DestinationType=queue">
                <source type="envelope"/>
                <target xmlns:s11=""
                        xpath="s11:Body/child::*[fn:position()=1] | s12:Body/child::*[fn:position()=1]"/>
             <callout serviceURL="jms:/MBQueue3?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&amp;java.naming.factory.initial=org.wso2.andes.jndi.PropertiesFileInitialContextFactory&amp;java.naming.provider.url=conf/;transport.jms.DestinationType=queue&amp;transport.jms.TransactionCommand=end">
                <source type="envelope"/>
                <target xmlns:s11=""
                        xpath="s11:Body/child::*[fn:position()=1] | s12:Body/child::*[fn:position()=1]"/>
             <log level="custom">
                <property name="Transaction Action" value="Rollbacked"/>
             <callout serviceURL="jms:/MBQueueDLQ?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&amp;java.naming.factory.initial=org.wso2.andes.jndi.PropertiesFileInitialContextFactory&amp;java.naming.provider.url=conf/;transport.jms.DestinationType=queue&amp;transport.jms.TransactionCommand=rollback">
                <source type="envelope"/>
                <target xmlns:s11=""
                        xpath="s11:Body/child::*[fn:position()=1] | s12:Body/child::*[fn:position()=1]"/>
       <parameter name="transport.jms.Destination">MyJMSQueue</parameter>
       <parameter name="transport.jms.ContentType">
          <rules xmlns="">
  4. Now, you can disable one queue in the Broker profile and send a message to the ESB profile. The proxy service will attempt to dispatch the message to all three queues. However, since one queue is unavailable, the message will not be delivered to any of the queues.

  • No labels