[ http://jira.jboss.com/jira/browse/JBTM-278?page=comments#action_12372503 ] Mark Little commented on JBTM-278: ---------------------------------- Any fix should be within the XAResourceRecord code and not the coordinator. That's because in general with 1PC, the outcome of the transaction is dictated by the single participant and not the coordinator. We try to optimise away the amount of intentions list processing we do, so that's why we don't call rollback on the participant. We should continue to do that in the coordinator (BasicAction), which is participant agnostic, and stick this fix in the prepare code for the XAResourceRecord. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBTM-278?page=comments#action_12372521 ] Jonathan Halliday commented on JBTM-278: ---------------------------------------- It is necessary to ensure that rollback is called on each XAResource exactly once, regardless of 'attempted commit fails' vs. 'explicit rollback' or one-phase vs. two phase paths through the code. Zero calls can leave the resource manager in an uncertain state, as now. More than one call may give spurious errors as the second one will probably throw an error. This probably means XAResourceRecord topLevelPrepare must never call it regardless of errors from the end call (the rollback call will happen during execution of topLevelAbort in phase two), topLevelAbort must always call it (it's either executing in phase two to clean up a failed prepare or on a single pass explicit rollback), and toplevelOnePhaseCommit mush call it in an exception handler if the end call throws an XA_RM* error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBTM-278?page=all ] Mark Little updated JBTM-278: ----------------------------- Component/s: JTA Implementation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBTM-278?page=all ] Mark Little closed JBTM-278. ---------------------------- Resolution: Done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBTM-278?page=all ] Mark Little closed JBTM-278. ---------------------------- Resolution: Done Closing because the original issue was addressed with code changes. I think it better to cover specific RM deficiencies in other issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira