Programatically setting a transaction to rollBack results in UnexpectedRollbackException [SPR-2231]

[spring-projects-issues]

Colin Yates opened SPR-2231 and commented

http://forum.springframework.org/showthread.php?p=67566#post67566

Essentially I am using aop:config and tx:advice to mark all my controllers transaction and introspecting into hibernate backed objects. If there is a validation error, we mark the current transaction rollBack. Since upgrading (not sure whether it was introduced in 1.2.x or 2.0rc1) we are now getting the following stack trace:

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
Caused by: org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:504)
at org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(TransactionAspectSupport.java:275)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)

It appears that neither TransactionInterceptor, nor the TransactionAspectSupport nor the transactionManager take into account whether the transaction is marked as rollback or not before committing.

---

Affects: 2.0 RC1

[spring-projects-issues]

Juergen Hoeller commented

As explained on the forums, the question here is whether the caller should receive an UnexpectedRollbackException at the outer transaction level in case of an inner transaction scope having silently marked the transaction as rollback-only. This is the transaction manager's choice, hence TransactionInterceptor will always call "PlatformTransactionManager.commit" in this case. The transaction manager will then detect the rollback-only marker and decide how to proceed. And the default behavior there is to throw an UnexpectedRollbackException if the outer transaction's code might not be aware of a rollback having happened...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

As per the forum discussion: clarified to be the expected behavior, since the programmatic setRollbackOnly call happened within an inner transaction. So the outer transaction was right to throw an UnexpectedRollbackException there.

FWIW, this behavior is largely analogous to the EJB setRollbackOnly rules, where there's also a differentiation between the current component having called setRollbackOnly for its own transaction (which is silently accepted) versus propagation to an outer component's transaction (which leads to an "unexpected rollback" exception at that level).

Juergen