[
https://jira.jboss.org/jira/browse/JBTM-66?page=com.atlassian.jira.plugin...
]
Jonathan Halliday commented on JBTM-66:
---------------------------------------
An intermediate solution that does not require changes to the public API is to cache a
stacktrace at the point setRollbackOnly() is called and attach it as the cause when a
RollbackException is thrown. This is similar to the technique the JBossAS
CachedConnectionManager uses.
setRollbackOnly() {
...
rollbackReason = new Throwable("STACKTRACE");
}
It still would not provide the original reason, but it would at least narrow down where to
look for it. I'm slightly concerned about the performance hit, but that's
probably premature optimization.
"Already marked for rollback" Exception could include
original cause
--------------------------------------------------------------------
Key: JBTM-66
URL:
https://jira.jboss.org/jira/browse/JBTM-66
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA Implementation
Affects Versions: 4.2
Environment: JBoss 4.0.4.CR2
Reporter: Richard Kennard
Assignee: Jonathan Halliday
Priority: Optional
Fix For: 4.6
Original Estimate: 1 week
Remaining Estimate: 1 week
First up, thank you for providing such a wondefully stable implementation! I have a small
feature request:
At present whenever a, say, SFSB throws a RuntimeException, JTA goes into
'rollback' mode. From then on, anyone who tries to do any further work (including
when the SessionContext tries to remove the rolled back SFSB) will trigger a different
RuntimeException saying, in short, 'Already marked for rollback'.
It would be very helpful if the 'Already marked for rollback' Exception could
include, as its getCause (which is standard as of JDK 1.4), the original exception that
started off the rollback? At present we are often left with the situation where all the
original caller gets back is a 'Already marked for rollback' Exception, and there
is no way to 'drill down' to find what the original cause was.
Of course, you could also argue that the SessionContext should be smarter about trying to
remove rolled back EJBs.
--
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