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

[Scott Marlow (JIRA)]

    [ https://issues.jboss.org/browse/JBTM-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764962#comment-12764962 ] 

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.


                
> provide way for Synchronization.afterCompletion callee to know if the Reaper thread is calling
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBTM-1556
>                 URL: https://issues.jboss.org/browse/JBTM-1556
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Core
>    Affects Versions: 4.17.3
>            Reporter: Scott Marlow
>            Assignee: Tom Jenkinson
>             Fix For: 4.17.4, 5.0.0.M3
>
>
> When the Synchronization.afterCompletion is invoked for EE JPA containers, knowledge of whether the current thread is the Reaper thread (cancelling the transaction from a background thread).
> The fix to this jira will help with handling the [JPA 2.1 container concurrency requirements|http://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-03/message/38].
> Please implement the solution makes the most sense to you, as this will introduce an additional dependency between other systems and JBossTM/JBossTS that depend on the solution, that will likely be around for a long time.

--
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