[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Steve Ebersole commented on JBTM-575:
-------------------------------------
I have to jump in here. Hibernate has not "messed" anything up. Yes I am
biased ;)
My understanding of setRollbackOnly (and the understanding of many many others) is that is
merely provides a fail-safe to ensure the transaction is not allowed to commit.
This is a pretty standard JTA usage pattern in case of error. In fact one now even
mandated by JPA2.
If y'all deem that you'd prefer to not have JBTM work with any JPA2 provider then
that is obviously your call. But I'd humbly suggest that you should be able to back
this up with relevant sections from the JTA specification. Either JPA is violating the
JTA spec or JBTM needs to support this IMHO.
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