[
https://jira.jboss.org/browse/JBRULES-2656?page=com.atlassian.jira.plugin...
]
Anatoly Polinsky commented on JBRULES-2656:
-------------------------------------------
but for the above, I think what we can do for now is to attach a
"t1.getStackTrace()" to the message while throwing t2. At least whoever has this
problem will be able to see the root cause of why it was _trying_ to rollback in the first
place.
/Anatoly
SingleSessionCommandService Eats an Actual / Real Exception on
Rollback
-----------------------------------------------------------------------
Key: JBRULES-2656
URL:
https://jira.jboss.org/browse/JBRULES-2656
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: All
Affects Versions: 5.1.0.FINAL
Environment: N/A
Reporter: Anatoly Polinsky
Assignee: Esteban Aliverti
Original Estimate: 1 hour
Remaining Estimate: 1 hour
org.drools.persistence.session.SingleSessionCommandService, line 287:
public synchronized <T> T execute(Command<T> command) {
try {
txm.begin();
... ... ... // omitted for clarity
txm.commit();
return result;
} catch ( Exception t1 ) {
try {
txm.rollback();
<<<<<<<<<<<<<< IF THERE IS A PROBLEM DURING
ROLLBACK, THE REAL EXCEPTION ( "t1" ) IS EATEN.
} catch ( Exception t2 ) {
throw new RuntimeException( "Could not commit session or
rollback", <<<<< THIS IS THROWN, BUT "t1" IS IGNORED
t2 );
}
throw new RuntimeException( "Could not commit session",
t1 );
} finally {
if ( command instanceof DisposeCommand ) {
this.jpm.dispose();
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira