According to the JTA spec:
This interface is intended for use by system level application server
components such as persistence managers, resource adapters, as well
as EJB and Web application components. This provides the ability to
register synchronization objects with special ordering semantics,
associate resource objects with the current transaction, get the
transaction context of the current transaction, get current
transaction status, and mark the current transaction for rollback.
Also:
The user of getResource() and putResource() methods is a library
component that manages transaction-specific data on behalf of a
caller. The transaction-specific data provided by the caller is not
immediately flushed to a transaction-enlisted resource, but instead is
cached. The cached data is stored in a transaction-related data
structure that is in a zero-or-one-to-one relationship with the
transactional context of the caller.
However I am still puzzled.
First, what does “[…] provides the ability to register synchronization objects with special ordering semantics” mean and how is it possible to setup the ordering?
Then, what are some use cases in which it’s necessary to “associate resource objects with the current transaction”?
The “special ordering semantics” are explained in the registerInterposedSynchronization javadoc, which is trying to explain how those listeners are fired relative to Transaction.registerSynchronization.
putResource/getResource let a caller store “transaction-local” objects.
For example, a JPA container might registerInterposedSynchronization when used. A stateful session bean might update an entity during SessionSynchronization.beforeCompletion. The EntityManager would store the entity on the current transaction using putResource, and then flush the data to the database during its Synchronization.beforeCompletion, which is guaranteed to run after.