[jbossts-issues] [JBoss JIRA] (JBTM-1556) provide way for Synchronization.afterCompletion callee to know if the Reaper thread is calling

[ https://issues.jboss.org/browse/JBTM-1556?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on JBTM-1556: ------------------------------------ Regarding the question about what I meant by the "remote thread" case: {quote} <tomjenkinson> smarlow: AS1:EJB1 enlists JPA(XAR1) then calls AS2:EJB2 over JTS <tomjenkinson> smarlow: AS2:EJB2 enlists JPA(XAR2) this is done by a jacorb request processor thread at random <tomjenkinson> smarlow: AS1:EJB1 calls commit on the transaction, JPA(XAR1) afterCompletion is handled in the same thread as before - this is fine - but then the call to AS2 to commit the transaction goes over a different jacorb request processor, now afterCompletion in AS2 is done by a different thread {quote} The above doesn't raise any concurrency concerns since there is no (active) application thread on AS2 at the time that AS2 invokes the Synchronization.afterCompletion. Another case, would be similar to the above but with one difference. AS1:EJB1 enlists JPA(XAR1) then loops on calling AS2:EJB2 over JTS AS2:EJB2 enlists JPA(XAR2) and does processing and returns Looping continues until the transaction times out while current application execution is in AS2:EJB2 or just in AS1:EJB1. I don't think that only checking the reaper thread name covers when the transaction times out when the application thread of execution, is in AS2:EJB2. Question 1: Does the root coordinator (AS1) reaper always handle transaction timeout or can the subordinate coordinator (AS2) reaper also handle transaction timeout? I'm not sure how the subordinate coordinator would handle timeout (maybe by sending an out of band message to its parent coordinator that propagates up to the root coordinator?) Even so, it would be chaotic to have multiple coordinators cancelling the transaction at the same time. Regarding the idea of having globally searchable "being cancelled" (I assume you mean by the reaper) list, sounds better than my current "reaper thread" name check. The globally searchable list would also cover the second (above) case when the application execution is in AS2:EJB2 while (concurrently) an AS2 background orb thread sees the cancel message from the root coordinator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira