Announcement Announcement Module
No announcement yet.
Is Spring Batch capable of participating in global transactions? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is Spring Batch capable of participating in global transactions?

    I have a job that reads items from a file, performs some business logic and then writes the resulting items (one by one) to a queue (with JMS). Items are then picked up by a message driven bean for further processing until there eventually persisted in a database. The commit interval is set to 20.

    The whole process runs in a global transaction (XA) because in case of an exception the items on the queue and the items persistent in the database should be part of the rollback. The problem however is that Spring Batch - more specifically ItemOrientedStep - calls commit() after the commit interval which is not allowed during a XA transaction.

    How to deal with this issue? Is Spring-Batch capable of using a XA datasource and running in a global transaction? My idea is that Spring-Batch should be in control of the transaction and 'commit' periodically on the commit interval and in case of an exception cause a rollback of the whole chain (read, write, queue, db). Since this rollback scenario is only possible with XA shouldn't Spring Batch find another way to commit items?
    Last edited by rkettelerij; May 15th, 2008, 03:26 AM. Reason: typo in title

  • #2
    Spring Batch can certainly participate in a global transaction, in the same way that all Spring projects can, using the JtaTransactionManager. You are correct that the step needs to have control over the commit and rollback of said transaction, which is absolutely allowed by the JTA spec via a UserTransaction. However, you need to make sure that you have turned off CMT on your application server. Otherwise, there should be no issues at all with Spring Batch calling commit and rollback.


    • #3
      Thanks for your quick response.

      We're using JtaTransactionManager (actually Oc4jJtaTransactionManager) and CMT combined with a XA datasource. Therefore I don't understand why you suggest turning CMT off?


      • #4
        CMT stands for 'container managed transaction', which essentially means 'declarative transactions'. Literally, the container is managing the transactions. When I've had it turned on with WAS in the past, the server wouldn't even let me have access to the UserTransaction through JNDI. Spring Batch *has* to have control of the transactions, the application server cannot be deciding when to commit or rollback.


        • #5

          Lucas, just wanting to let you know that the issue described above isn't related to Spring Batch. The problem was that items on the queue were - in case of failure - not part of rollback. This was due to incorrect configuration of the messaging system. Furthermore the messaging system complained about explicit commits, which also wasn't related to Spring Batch.

          All-in-all the scenario described above (Spring-Batch is in control of the transaction and commits periodically on the commit interval and in case of an exception causes a rollback of the messages on the queue) works just fine.