We've got the same problem. I wrote a test to force a ConstraintViolationException. If I'm not using Envers then the CVE is thrown and is caught by my business logic. As soon as I enable Envers I get
javax.transaction.RollbackException: ARJUNA016063: The transaction is not active!
This is because of the following code in the SynchronizationCallbackCoordinatorImpl:
< { code > }
try {
if ( flush ) {
LOG.trace( "Automatically flushing session" );
transactionCoordinator.getTransactionContext().managedFlush();
}
}
catch ( RuntimeException re ) {
setRollbackOnly();
throw exceptionMapper.mapManagedFlushFailure( "error during managed flush", re );
}
finally {
transactionCoordinator.sendBeforeTransactionCompletionNotifications( null );
transactionCoordinator.getTransactionContext().beforeTransactionCompletion( null );
}
</ { code > }
The tx "successfully" fails during flush with a CVE. But within the finally clause all tx listeners are notified as if the tx would still be running. Envers therefore tries to audit all changes and causes a RollbackException.
|
HHH-8181
