JPA entities can frequently be involved in an XA transaction; that is, a transaction that uses more
than one database resource, or a database resource and another transactional resource (such as a
Committing a transaction across different transactional resources is a very expensive opera-
tion—the algorithm to perform that implements the eXtended Architecture (XA) standard for
committing data. It is a very clever and very complex operation that requires multiple back-and-
forth exchanges among the resources involved in the transaction.
Most Java EE application servers will allow an optimization in this situation whereby the last re-
source can bypass the normal XA protocol. This optimization is known as the Last Agent Optim-
ization (LAO), the Logging Last Resource (LLR) optimization, the Last Resource Commit Op-
timization (LRCO), the Last Resource Gambit, and probably other names.
Technically speaking, these optimizations are not exactly the same. In particular, the LLR and
LRCO optimizations provide full ACID compliance as long as the last agent is a JDBC resource
capable of storing the XA logs. Some implementations of LAO do that, and some do not. If the
JPA database can be used as the transaction log in an application server that supports some form
of LAO, then transactions will be noticeably faster because the database updates don't need to
participate in the XA protocol. They will also be ACID compliant.
If the LAO implementation does not store the transactions logs like that, it will still give a large
performance benefit—just be aware that if there is a crash in the middle of a transaction involving
such a resource, the crash cannot be automatically recovered. Human intervention will be re-
quired to look at pending and recently committed data and manually roll back some items to
achieve data consistency.
1. Explicitly managing transaction boundaries with user-managed transactions can
often improve the performance of an application.
2. The default Java EE programming model—a servlet or web service accessing JPA
entities via EJBs—supports that model easily.
3. As an alternative, consider splitting JPA logic into separate methods depending on
the transactional needs of the application.