[jbossts-issues] [JBoss JIRA] Commented: (JBTM-748) Calling rollback_only via OTS is throwing the wrong exception
Michael Musgrove (JIRA)
jira-events at lists.jboss.org
Tue Jan 25 10:28:50 EST 2011
[ https://issues.jboss.org/browse/JBTM-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577759#comment-12577759 ]
Michael Musgrove commented on JBTM-748:
I'm seeing other undesirable consequences of this error. I added a hack to our BlackTie C++ code to assume that the transaction rolled back but once the error has occurred whenever a new (OTS) transaction is started any attempt to get the propagation context results in the ORB running inside the AS reporting the following failure:
"12:55:46,180 WARN [controller] rid: 25 opname: get_terminator cannot process request, because object doesn't exist" (which we see as CORBA::OBJECT_NOT_EXIST exception)
The only way to recover is to shutdown and restart the ORB running in the BlackTie C++ executable.
> Calling rollback_only via OTS is throwing the wrong exception
> Key: JBTM-748
> URL: https://issues.jboss.org/browse/JBTM-748
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTS
> Affects Versions: 4.11.0
> Reporter: Michael Musgrove
> Assignee: Andrew Dinn
> Fix For: 4.15.0
> Occasionally our BlackTie CI test run is failing when marking a transaction rollback only because it is getting the wrong exception back from the transaction manager
> 16:11:10,296 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_18] - TransactionReaper::check timeout for TX -53ee7cfb:10e2:4c0fa834:22ec in state RUN
> [exec] 2010-06-09 16:11:10,296 [0x0000123c] WARN (TxLogControl :153 ) - rollback_only: INVALID_TRANSACTION minor: 20001
> 16:11:10,328 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_7] - TransactionReaper::doCancellations worker Thread[Thread-18,5,jboss] successfully canceled TX -53ee7cfb:10e2:4c0fa834:22ec
> The second log message comes from the C client (the other two from the reaper). The CORBA System exception major/minor code represents INVALID_TRANSACTION/INACTIVE_TRANSACTION which according to the OTS spec is incorrect.
> A look at the code shows a race condition between a BlackTie C client marking a transaction abort only and the Transaction Reaper cancelling it (due to a timeout being reached). The reaper eventually winds up in ControlImple.destroy() where the CORBA object representing the transaction is destroyed. There is a window where the C client request reaches JacORB just before the reaper has had a chance to destroy the CORBA object resulting in the wrong exception being returned.
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbossts-issues