Home/ Questions/Q 8173477
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T22:10:20+00:00

I’m trying to understand JTA and am using Bitronix as the Transaction Manager of

  • 0

I’m trying to understand JTA and am using Bitronix as the Transaction Manager of choice (just for the sake of learning and understanding). I’m looking at the code inside the Bitronix reference guide here and am wondering to myself: If I’m using JDBC, which itself is transactional (Connection can be committed/rolled back), why would I ever want to write code like that?!?!

Now maybe the point of that code snippet was to simply demonstrate how to use Bitronix/JTA over an existing transactional datastore, but I still don’t get what inherent benefits it offers.

Then, this code snippet got me thinking: “If the only two main datasources you use are databases and message brokers, and you use JDBC/JMS to communicate with them respectively, and these two standards (JDBC/JMS) are already transactional, then why would you ever need to use JTA at all?!?!“

Is JTA some sort of an “internal” Java EE API that JDBC, JPA, JMS, etc. all use; and is only publicly-exposed for the 1%ers out there that want to do something crazy with it? Or am I missing the idea/applicability of JTA altogether?

I guess I could envision two non-JDBC and non-JMS use cases for directly hitting JTA, but since I’m so fuzzy on JTA in the first place I have no idea if these cases are off-track or not:

  • Perhaps you have a complicated I/O system in your app andhave multiple threads reading to/writing from the same file on disk. Perhaps you would have each thread use a transaction to write to this file. (Yes?!? No?!?)
  • Perhaps you have a state machine POJO representing the state of a system, and multiple threads can modify the machine. Perhaps you would have each thread use a transaction to alter the machine’s state. (Yes?!? No?!?)

I guess at the root of my question is:

  • If my JPA (Hibernate) and/or JDBC calls are already transactional, why would I want to wrap them inside JTA begin->commit/rollback block? Ditto for JMS and messaging systems.
  • Outside of JPA/JDBC/JMS, what use cases exist for using JTA to transact a series of operations?

Thanks in advance!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It is more than just rolling back open transaction, JTA provides an XAResource interface which providers can implement, your JDBC driver and JMS provider will already do this and you can implement your own. This is based on an open standard and is probably worth reading about.

    Now why would we want this?

    Consider Matthews example in a disaster:

    Begin DB Transaction

Set AccountBalance $100 lower for Account #345 in database

Add JMS Message "Transfer $100 to OtherBank Account #987" to queue

*** DB power is unplugged while committing DB Transaction ***

    Unfortunately the JMS message has gone to the other bank, this is a very real problem with distributed transactions.

    With XA this is how the scenario will play out:

    DB Transation starts XA Transaction

Set AccountBalance $100 lower for Account #345 in database

JMS Connection joins XA Transaction 

Add JMS Message "Transfer $100 to OtherBank Account #987" to queue

Everything went okay and JTA context is ready to commit.

DB and JMS both agree that they are capable of commiting.

JTA instructs DB and JMS to commit.

All members of the transaction commit.

    Now you may ask what happens if the power plug is pulled out during the DB’s final commit. Well the JMS queue will have commited, however the XA transaction will remain open until the DB is once again available, at which point it will again instruct the DB to commit (the DB promised us it can commit, this is part of being XA compliant).

    What is REALLY great about JTA is that you can easily implement your own custom XAResource and tie into this great framework!

    UPDATE

    So to answer your question about when to implement custom transactions you can ask yourself the following:

    1. Is your custom state or file UNABLE to be the final code block in the transaction scope?
    2. Do you need to revert your custom state / file upon external systems (ie. DB or JMS) failure?
    3. Is a simple getRollbackOnly() & setRollbackOnly() for external systems, coupled with compensation handling (ie. revert custom state / file explicitly) for your custom code insufficient?

    If the answer to both 1, 2 & 3 is YES then you probably want a custom XAResource, otherwise I think it is probably overkill.

    However if your code is a framework or library which will be enlisted by business logic in the Java EE space, you may want to implement an XAResource for it!

    • 0