Blog, Trixi

JTA transaction manager – Atomikos or Bitronix?

Recently I was faced with a problem of choosing an appropriate transaction manager for one of our server-side applications.

Transaction manager requirements:

  • JTA compliant
  • integrates with Spring
  • open-source and free
  • support of several different resources: Postgresql with pooled connections, ActiveMQ (JMS), XADisk (filesystem)
  • easy usage
  • one-phase commit optimization

With the exception of XADisk, these are pretty common requirements.

Doing a little searching, I’ve found following transaction managers:

The first three seemed worth a try. Last one looks like a dead project and I do not like it.

Finally, I ended up with Bitronix, but it wasn’t easy to choose.


Firstly I tried Atomikos. Seemed most mature and well documented. Unfortunately, it is NOT that mature. Let’s look at major problems I was facing with Atomikos.

1) Poor logging and exception handling:

  • In some cases, Atomikos incorrectly reported (swallowed) exceptions coming from Postgresql in prepare phase of two-phase commit. Only some general purpose exception was logged and it was impossible to find a true cause of the error in the log. This issue is generally related to poor exception handling in Atomikos.
  • Message log levels are insane. Atomikos logs quite a lot of messages on INFO and WARN level. This is not a big deal, but it is annoying and inconsistent with a common usage of log levels.
  • Bug: without any apparent reason this message is  often logged: WARN atomikos – Forcing close of pending statement: Pooled statement wrapping physical statement null
  • Unclear logging configuration

2) Disabled support for one-phase commit optimization:

  • even if the transaction works with a single resource, the two-phase commit is always used
  • there is a note in the Atomikos source code saying that this behaviour is a consequence of some unrelated bug-fix

Despite all of this, I managed to use Atomikos and it worked. But I’ve been somehow disappointed with all that small problems. So I decided to try Bitronix.


It works in a similar manner like Atomikos. The only difference is that Bitronix does not support XADisk out-of-the-box. I had to do a little programming to get it working. After that, Bitronix works very well and does not suffer with any of the Atomikos’s issues. I am simply satisfied.

Bitronix and XADisk

XADisk documentation contains a brief description of how to enable XADisk in JTA environment.

To make it work with Bitronix, you need to do a little bit more. Here is  what I have done.

1) Implement two new classes:

  • Create a new implementation of interface XAResourceProducer for XADisk – take Ehcache implementation and just copy/rename it
    • class name: XaDiskResourceProducer
  • Similarly – create a new implementation of  XAResourceHolder from Ehcache version
    • class name: XaDiskXAResourceHolder
  • (edit: Dec 04, 2011) As a last step, I’ve modified a small part of the XaDiskResourceProducer to ensure proper registering/unregistering of the resources (methods registerXAResource and unregisterXAResource)

Look at my clasess: bitronix-xadisk-v2 (edit: Dec 04, 2011)

2) For every transaction where you need an XADisk session you must follow these steps:

  • Register XADisk’s XAResource into Bitronix using static method registerXAResource() on your XAResourceProducer implementation
  • Enlist XADisk’s XAResource into every transaction where you are using XADisk
  • Unregister XADisk’s XAResource from Bitronix

My solution:

XASession xaSession = xaFileSystem.createSessionForXATransaction();
final XAResource xaResource = xaSession.getXAResource();
XaDiskResourceProducer.registerXAResource( "MAIN", xaResource );
transaction.enlistResource( xaResource );
transaction.registerSynchronization( new Synchronization() {

  public void beforeCompletion() {

  public void afterCompletion( int status ) {
    XaDiskResourceProducer.unregisterXAResource( "MAIN", xaResource );
} );

JBoss Transactions

I gave it only a few minutes and have no real experience with it. Its documentation is kind of old-school and hard to use.


Bitronix met 100% of our requirements. Despite its design-less web site, it’s usable and easy to configure. Its source code looks much better than that of Atomikos. I simply trust it more.

Bitronix works well with Postgresql and is extensible to allow usage of XADisk for filesystem transactions. This is what I tried so far.

We don’t have Bitronix deployed in a production environment yet, so I have no production use experience. Especially I have not tested its ability to work with JMS – I will add this part as soon as I get to it.

Posted in programming

6 Responses to “JTA transaction manager – Atomikos or Bitronix?”

  • Guy Pardon says:


    Thanks for the feedback. I am closely involved in Atomikos and many of the issues you report here are things we’d like to address. Are you interested in helping us?


  • Guy Pardon says:

    BTW: I checked to be sure and “Bug: without any apparent reason this message is often logged: WARN atomikos – Forcing close of pending statement: Pooled statement wrapping physical statement null” -> this is because we actually fixed a very serious bug that still exists in most other TMs (not to mention any one in particular), and we log to that effect. So this is arguably a reason to call Atomikos “not so mature” :-)


    • gargii says:

      The reason why I used a “not so mature” qualification was that it have not met my personal quality standards. The log message you write about certainly was not the main reason.

  • Guy Pardon says:

    OK thanks anyway – most of your complaints will likely be addressed in an honest attempt to meet your personal quality standards in a future release!

  • Sebastian says:

    I have tested Atomikos and Bitronix in a JMS integration setup and found them both very reliable and fast – I never lost messages. I wouldn’t hesitate to recommend both.

    I had to increase Bitronix transaction log files (2×2 MB was to small) to avoid duplicate messages after crashes on very high load JMS routes. With Atomikos that was not necessary since it manages the tx log files in a different way.

    It seems to me that XA is still a difficult thing to get right – not because of the tx managers, they are mature, but because of often poor quality XA drivers of JMS brokers and databases.

    That Guy Pardon of Atomikos was asking for more info on your problems says something about Atomikos too, I think.

  • Philip Co says:

    I just tried both Atomikos and Bitronix.

    BIG problem with Atomikos is that after 2 days, I have yet to figure out how to inject the username and password into its AtomikosConnectionFactoryBean. I was able to do the same thing with Bitronix in less than one hour. I went with Atomikos first because it’s more “famous”. But then it turns out the smaller product was easier to use.

    As for Guy Pardon asking for more info on problems, take a look at this:

    This is pretty much the same issue I am seeing. Why did they “freeze” that page ?

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>