|
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
