Tuesday, July 3, 2007

JTA Does Not Equal Automatic Support of Two-Phase Commit!

I find it a little bit distressing how few Java developers understand that using JTA does not automatically get you XA/Two-Phase-Commit capabilities.

Here we’ve got Matt Raible, who really should know better, or at least should not be blogging about it, posting on Two Phase Commit in Tomcat with JOTM and Spring. Somebody flew out to see Matt, and they spent some time setting up a system with TomCat and JOTM, and apparently they went away thinking their app was now XA capable. I wouldn’t want to be using this app in production if they’re depending on coordinated rollback across multiple datasources.

Now it looks like JOTM is getting (it’s in CVS, and part of a new Jonas reelase) XA recovery, but the release version doesn’t. I really welcome a version of JOTM which can do proper XA recovery. It’ll be great to have that option, but until that’s actually available there’s not really much of a reason you’d ever want to use JOTM in a new Spring app deployed in TomCat.

Without the full XA capabilities, the only thing JOTM really adds is making the standard JTA apis available (the UserTransaction and TransactionManager interfaces), but Spring itself doesn’t need those, it can handle non-XA transactions in a very performant and robust fashion with just a local Spring transaction manager like HibernateTransactionManager or DataSourceTransactionManager. Bringing JOTM into the picture will just add overhead and another potential source of problems (certainly in the past JOTM was not the most robust or spec-complete piece of software around, although from what I know it’s gotten a lot better).

Now if you have user code which needs to work agains the JTA apis (without needing XA), that _would_ be a reason to bring in JOTM. It’s just not needed for Spring-only apps. So if you’re deploying a non-Spring app, or perhaps have an app which is partially using Spring transaction management and partially (for legacy reasons) working against JTA, JOTM may make some sense But you still won’t get XA.

Also, aside from the transaction manager, to get proper XA recovery capabilities, your JDBC driver and database itself need to be XA capable. You’re not going to get 2PC with HSQLDB no matter what JTA driver you use…

One note to people looking for 2PC like functionality in a Spring environment, for other kinds of non-transactional data, such as LDAP access. You can actually pretty easily hook into the Spring transaction synchronization, so that for example when a database transaction which writes a partial user record to the db rolls back, you can also do something like a manual rollback (via the synchronization) of the data you wrote to LDAP.

By Colin

1 comment:

Shannon Lal said...

I am implementing a solution using Spring in a Tomcat environment. We will need to do distributed transactions across two databases. Since we are running on Tomcat is it correct that the only solution we have is to use JOTM? Do you know if the current releases of JOTM has full rollback capabilities?