Java EE: Why use JTA directly?

Question

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!

Anatomical

Answer 1

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!

Stringfellow

Thanks for the great answer @Stringfellow (+1). What about the examples I am citing (file reading, state manipulation, etc.)? Are those instances when one would want to transact (why or why not)? If so, would I need to implement my own XAResource for them? Again, for the bounty, I'm looking for a set of guidelines to use when deciding whether or not something should be transacted. Thanks again! – Anatomical

@AdamTannon thanks for the +1! I added some of my own guide lines, I hope they're helpful. – Stringfellow

Answer 2

You can have one transaction that covers both the database and the message service. I don't know of any way to do that without JTA.

Simple conceptual example. The exact code is not important:

Begin JTA Transaction

Set AccountBalance $100 lower for Account #345 in database

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

Commit JTA Transaction

OtherBank is a separate bank, and we assume you communicate with it over JMS.

The Begin Transaction and Commit are handled by JTA. If adding it to the queue fails, the withdrawal also rolls back automatically.

Real life isn't quite so simple, but this should give you an idea.

EDIT:

JTA can be used any time part of the system can correctly implement the XAResource. By implementing that, a resource can participate in distributed transactions. At first glance, both of your proposed examples could possibly implement XAResource.

"a complicated I/O system in your app and have multiple threads reading to/writing from the same file on disk." - This sounds like it could be a database, if you think about it.

"Perhaps you have a state machine POJO representing the state of a system, and multiple threads can modify the machine." - This could definitely be a candidate, if changes can be isolated sufficiently.

I think the first part of the rubric is basically that the resources logically could be XAResources. In other words, the concept of ACID is meaningful. The second is that it's possible and worth the effort to implement that interface (where it isn't implemented already).

Wojak

Thanks Matt (+1) but please remember I'm completely new to JTA (and to most degrees, Java EE in general). Can you provide a code example of what you are talking about (or be more specific)? I guess I'm not seeing the "forest through the trees" here...why would I want to transact the same set of operations to both a database and a message broker? – Anatomical

@AdamTannon, I'm new to JTA too. But I've provided a conceptual example. – Wojak

Ahhh, so JTA makes operations transactable across multiple resources, yes?!? If that's correct then I "get it"!! Thanks again – Anatomical

Answer 3

In my opinion, the first consideration is to decorolate the TX manager and the TX system.

When I design my application, the word Transactional mark my intent to do something ACID. I want to put this intent in my business code as this should be driven by a business need.

I expect something magic (my container in the real life) will weave my tx intents correctly, depending the underlying TX system (database, jms broker, etc.)

Moreover, JTA defines somes interfaces to allow integration between an existing JTA system and a (eventually new, eventually exotic) TX system. For example: GigaSpaces XAP is an in-memory datagrid. It is not JMS, not SQL, but it's easy to plumb it as it provides a JTA integration. We could quote many other products...

Obviously, the killer example is the support for XA transactions between different systems (I give a point to Justin). My point is to say JTA has value even if you don't use XA transaction.

Disused