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.

There is by the way a great series of articles on XA and 2-phase-commit, written by Mike Spille, available here. These are truly in depth and well worth reading.

 

8 responses

  1. jsalvo says:


    Hi Colin,

    Thank you for this blog. I have been battling with myself whether or not to replace an exising part of a system I maintain that currently polls a database table ( by continually SELECTing from the table ) for new “messages” … and replace it with JMS message queue which is more natural.

    Problem then is, I need to have JMS operations + other JDBC operations as part of a single transaction, even if I will be persisting JMS to the same database that the other JDBC operations will operate against.

    Of course with JMS, the actual persistence is abstracted and therefore, you don’t get access to the JDBC connection ( the JMS provider could be persisting to a file ). Thus, the only way it would work was if both JMS and JDBC were XA resources. However, going back to the scenario that I have …. there is really just one database for both JMS and JDBC ops.

    Since I only have one database, does my RDBMS ( Sybase ASE ) therefore need to be XA-enabled ? Do I still need XA-enabled JDBC drivers ?

    My personal answers are yes and yes, since you will essentially have 2 connections to the same database, and the transactions on both connections will still need to participate in 2PC.

    Furthermore, I could not find a decent open-source stand-alone JTA provider that does XA recovery ( JOTM probably now does, who knows ).

  2. Anonymous says:


    This was also pointed out by Guy Pardon a couple of years ago.
    http://www.onjava.com/pub/a/onjava/2003/07/30/jotm_transactions.html?page=2

  3. Carmo says:


    See
    Atomikos TransactionsEssentials™

    Reliability through atomicity, the easiest way: this product is a premium transaction manager for automatic cancelation of problematic transactions, across disparate datasources or back-end systems. Unlike CICS™ (IBM, mainframe) or Tuxedo™ (Bea, workstations), our product is optimized for easy integration into Java™-based solutions:

    open source: gives you control and transparency (apache license)
    professional support available directly from the developers
    very easy to learn in less than 1 day (includes demos and docs)
    a very small memory footprint
    100% Java™: seamless compatibility with any Java™ application
    JTA/XA compliant: instant JTA/XA transactions with full recovery and nested transactions
    Integration into your code can be as simple as one line of code… Because it’s open source, this product is completely yours to use

  4. Tracey Annison says:


    I’m trying to comment on this post, and ask for help, but it doesn’t seem to be going through… let’s try again…

    ================================================================
    Cool info! But I have Tomcat 5.5 and Spring 1.2.8, and two completely different databases, (iSeries via IBatis and JTOpen, PC SQL MySql & MSSQL Server & Postgresql) and I need to implement service-level transaction control over both of them.

    Everything I see tells me that I need JOTM to allow Spring to do that using JTA, as Tomcat doesn’t natively support it… is there a better way?

    I’m having zero luck in even setting it up via Spring, so any help gratefully recieved.

    Cheers
    Tracey

  5. Tracey Annison says:


    That’s better - it posted this time. I’d really appreciate any help I can get on the above issue, as I seem to be getting nowhere fast! :)

    Thanks again…

  6. Colin Sampaleanu (blog author) says:


    You could actually try Atomikos:
    http://www.atomikos.com/home.html
    It was open sourced a little while ago, and I’ve heard pretty good things about it. From what I know it’s fully XA capable.

  7. Tracey Annison says:


    Thank you! I’ll have a look at that.

    So JOTM isn’t any good, then?

    Cheers,
    Tracey

  8. Stephane Clinckart says:


    Hi Collin,

    I would like to have your opinion…
    I should like to use Spring interceptor mechanism for transaction on files CRUD operation.

    Please look at this post: http://forum.springframework.org/showthread.php?p=161920#post161920

    Thanks a lot for your help.

    Cheers,
    Stephane

One trackback

Leave a Reply