The Java Transaction API

The Java Transaction API (JTA) is the element responsible for providing the API responsible for ensuring the consistency of your data in the widest sense. In our quote manager, it is only applied to the database data but it can be applied to JMS messages, potentially files if you use connectors, and so on.

Without going through the details and protocol, the idea is to ensure, across multiple systems, that either all commits or all rollbacks but not something in between are done ensuring the consistency of the system (which is one common issue mixing NoSQL systems).

To do that, JTA uses what we call a two phases commit protocol:

• Ask all systems to prepare the commit which means the system must verify and ensure it will be able to commit in next phase
• Ask all systems to actually do the commit

A lot of transaction manager or servers are optimized for the case of a single resource to limit all the associated overhead.

In our quote manager application we only have a database, so we should benefit from these optimizations in most servers. Nonetheless, we still use JTA backbone and don't fallback on JPA transaction management (RESOURCE_LOCAL) which is faster.

What is important to know with JTA is that a transaction is bound to a thread. Each resource has its representation and identifier, a complete lifecycle (see XAResource). There is a transaction bound registry to store the data (a bit like a @TransactionScoped bean) and the listeners to integrate with the transaction lifecycle.

All of that is not true in terms of memory and CPU cycles but can be justified if you need it, either because you have multiple systems or because you use your server JTA monitoring (you rarely have monitoring with RESOURCE_LOCAL in administration UI).