Class TransactionSynchronizationRegistryWrapper
java.lang.Object
org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper
- All Implemented Interfaces:
jakarta.transaction.TransactionSynchronizationRegistry
public class TransactionSynchronizationRegistryWrapper
extends Object
implements jakarta.transaction.TransactionSynchronizationRegistry
Most of this implementation delegates down to the underlying transactions implementation to provide the services of the
TransactionSynchronizationRegistry. The one area it modifies is the registration of the interposed Synchronizations. The
reason this implementation needs to differ is because the Jakarta Connectors Synchronization and Jakarta Persistence Synchronizations are both specified as
Interposed however there are defined ordering requirements between them both.
The current implementation orders Jakarta Connectors relative to all other Synchronizations. For beforeCompletion, it would be possible to
restrict this to the one case where Jakarta Connectors are ordered before Jakarta Persistence, however it is possible that other interposed Synchronizations
would require the services of Jakarta Connectors and as such if the Jakarta Connectors are allowed to execute delistResource during beforeCompletion as
mandated in Jakarta Connectors spec the behaviour of those subsequent interactions would be broken. For afterCompletion the Jakarta Connectors
synchronizations are called last as that allows Jakarta Connectors to detect connection leaks from frameworks that have not closed the Jakarta Connectors
managed resources. This is described in (for example)
http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry
.html#registerInterposedSynchronization(jakarta.transaction.Synchronization) where it says that during afterCompletion
"Resources can be closed but no transactional work can be performed with them".
One implication of this approach is that if the underlying transactions implementation has special handling for various types
of Synchronization that can also implement other interfaces (i.e. if interposedSync instanceof OtherInterface) these
behaviours cannot take effect as the underlying implementation will never directly see the actual Synchronizations.
-
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptiongetResource(Object key) booleanintvoidputResource(Object key, Object value) voidregisterInterposedSynchronization(jakarta.transaction.Synchronization sync) void
-
Constructor Details
-
TransactionSynchronizationRegistryWrapper
public TransactionSynchronizationRegistryWrapper()
-
-
Method Details
-
registerInterposedSynchronization
public void registerInterposedSynchronization(jakarta.transaction.Synchronization sync) throws IllegalStateException - Specified by:
registerInterposedSynchronizationin interfacejakarta.transaction.TransactionSynchronizationRegistry- Throws:
IllegalStateException
-
getTransactionKey
- Specified by:
getTransactionKeyin interfacejakarta.transaction.TransactionSynchronizationRegistry
-
getTransactionStatus
public int getTransactionStatus()- Specified by:
getTransactionStatusin interfacejakarta.transaction.TransactionSynchronizationRegistry
-
getRollbackOnly
- Specified by:
getRollbackOnlyin interfacejakarta.transaction.TransactionSynchronizationRegistry- Throws:
IllegalStateException
-
setRollbackOnly
- Specified by:
setRollbackOnlyin interfacejakarta.transaction.TransactionSynchronizationRegistry- Throws:
IllegalStateException
-
getResource
- Specified by:
getResourcein interfacejakarta.transaction.TransactionSynchronizationRegistry- Throws:
IllegalStateException
-
putResource
- Specified by:
putResourcein interfacejakarta.transaction.TransactionSynchronizationRegistry- Throws:
IllegalStateException
-