[jbossts-issues] [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause

[Ali Lahijani (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12523720#action_12523720 ] 

Ali Lahijani commented on JBTM-575:
-----------------------------------

It is very unfortunate that a adding a useful piece of debug information has caused such a problematic regression. But as I understand, there as a really simple solution to this: just make _theTransaction.getDeferredThrowable() take precedence over _rollbackOnlyCallerStacktrace as the cause of the RollbackException.

The JPA spec states this under 5.9.2 Provider Responsibilities:
"When the provider throws an exception defined to cause transaction rollback, the provider
must mark the transaction for rollback."

This is what the Hibernate guys quote when they state that they are just implementing what the spec says. First mark the transaction for rollback and then throw the exception. I am not aware of what the JTA spec mandates for a situation when both setRollbackOnly is called on the TransactionManager and an exception is also thrown by a beforeCompletion() method. The two events may be related (as in JPA) or completely unrelated. But since the exception chaining mechanism also allows one cause for an exception, we need to decide when we have them both. 

In any case, the exception from the user code is evidently more eligible as the cause of the RollbackException, rather than the synthetic Throwable created in setRollbackOnly() because most likely it contains business information, thing like validation messages and Hibernate consistency errors which are relevant to the user and indeed many apps (including ours) rely on this information for their application logic. After all, setRollbackOnly having been called is mostly treated like a booelan condition in JTA spec.

Let me emphasize the importance of this. _theTransaction.getDeferredThrowable() should never be ignored when it contains information, and that information should be carried over to the cause chain of the RollbackException. However, when it is null and we are aborting, then someone must have called TransactionManager.setRollbackOnly(), so it will be helpful for debugging purposes to let them know who called that method.



> 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