Warning: A non-numeric value encountered in /home/ricston2/public_html/blogarchive/wp-content/themes/Divi/functions.php on line 5766

When someone mentions XA transactions during a conversation with a developer, you will most likely see the developer give an expression of disapproval, and then try to do everything to eliminate the XA transactions from the equation! While XA transactions solve a very interesting and involving problem, they perform slower when compared to single resource transactions, and are a headache to implement (ask some of the developers out there).

Sometimes even though you do your best, its not possible to avoid such transactions, so the developers have to give in. One of the recent projects we worked on included a lot of XA transactions being carried out between an Active MQ JMS server, and a MySql database. All messages were routed using the latest Mule 3.2.0, where Mule was pulling off message from some JMS queues, and updating the database accordingly. In between, we did a lot of trickery stuff, but that is not important for this blog. The XA transactions were being handled by Mule, so if you look at the Mule configuration file, you will see a lot of inbound endpoints looking like this:


	
		
	
	...

and outbound endpoints which look like this:


	...
	
		
	
	...

After having completed this project, we would like to share some tips. The first problem we encountered was that MySql was not participating in the XA transactions. This was very interesting because the Mule configuration looked perfectly fine, however Mule was not throwing any exception at all, and the SQL statements were just being committed independently. After digging around a bit, we found this page on the MySql web site. The gist of this page says that if you want MySql to be able to participate in XA transactions, your tables have to use the InnoDB engine. By default when you create tables in MySql, the configuration uses MyISAM engine, so be careful when creating your tables!

The second tip that we would like to put out there is to make sure to use the correct client version of ActiveMQ depending on the server you are using. Unfortunately during this project, we had a version mismatch where our ActiveMQ server was 5.4.2 and in our Mule project, we were using the 5.5.0 ActiveMQ core dependency. The behaviour was very erratic, we were losing messages without seeing any exceptions on the Mule side! When we swapped the client jar with 5.4.2, everything worked perfectly! However we also have to note that when we tried with ActiveMQ server 5.5.0 and client jar 5.5.0, we still experienced erratic behaviour, so we are not sure whether this was a problem because of a version mismatch or whether server/client version 5.5.0 has some bugs. Either way, be careful when choosing the version for ActiveMQ when using XA transactions…