[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Jonathan Halliday commented on JBTM-575:
----------------------------------------
at
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.setRollbackOnly(BaseTransactionManagerDelegate.java:123)
at
org.hibernate.ejb.AbstractEntityManagerImpl.markAsRollback(AbstractEntityManagerImpl.java:421)
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:576)
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)
at
org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:513)
What's key here is that, from the transaction manager's perspective, the
setRollbackOnly call precedes the exception - hibernate sets the tx to rollback before
throwing the exception. So, the setRollbackOnly call IS the root cause of the transaction
rolling back. JBTM-66 is not only present but functioning exactly as designed. As
mentioned in the forum thread, this is arguably misuse of the api by hibernate.
Of the alternatives proposed in the forum thread, chaining the deferredThrowable to the
rollbackOnly trace won't work, as there is no deferredThrowable at the point in time
that the setRollbackOnly call is made. So the only viable alternative seems to be using
the deferredThrowable as the initCause of the rollback in preference to the
rollbackOnlyCallerStackTrace in cases where both are available. Will that meet your
needs?
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL:
https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira