| Since Hibernate 5.2.x native HibernateExceptions are in many cases automatically wrapped in JPA exceptions via AbstractSharedSessionContract#exceptionConverter though not consistently, see  HHH-12666 Closed If a HibernateException is thrown in the commit phase, and it is converted to a JPA exception, the following code inActionQueue.BeforeTransactionCompletionProcessQueue does not expect a JPA exception, so it wraps the JPA exception in an AssertionFailure, which is clearly not the intended result: public void beforeTransactionCompletion() {
while ( !processes.isEmpty() ) {
try { processes.poll().doBeforeTransactionCompletion( session ); } catch (HibernateException he) { throw he; } catch (Exception e) { throw new AssertionFailure( "Unable to perform beforeTransactionCompletion callback", e ); } }
} This causes any client code which may potentially be expecting to catch either JPA or HibernateExceptions in the commit phase to fail. The solution is propagating JPA exceptions just like HibernateExceptions. Currently, the workaround is enabling hibernate.native_exception_handling_51_compliance as implemented by HHH-12666 Closed which anyway seems to be preferred overall, since the transition to JPA exception seems to be quite inconsistent, plus client code is still in most cases expecting HibernateExceptions instead of JPA exceptions (the Spring integration in particular deals only with HibernateExceptions in most places, even though some support for JPA exceptions thrown by Hibernate was added in the latest releases). |
