[jboss-jira] [JBoss JIRA] (WFLY-7838) EJBClient user transaction is not propagated properly to the receiver

[Mate Varga (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mate Varga updated WFLY-7838:
-----------------------------
    Description: 
Setup:
- WF 10.1.0.Final
- two deployments, one EAR and one WAR
- EAR exposes EJB methods (SFSBs and SLSBs)
- WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs

Problem:
The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:

- LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
- EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
- processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
- later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
- it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
- it does not find the userTransaction there

It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.


  was:
Setup:
- WF 10.1.0.Final
- two deployments, one EAR and one WAR
- EAR exposes EJB methods (SFSBs and SLSBs)
- WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs

Problem:
The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:

- LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
- EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
- processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
- later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
- it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
- it does not find the userTransaction there

It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
In other words, if this line:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/EJBRemoteTransactionPropagatingInterceptor.java#L67
would be 
{{final TransactionID transactionID = (TransactionID) context.getContextData().get(AttachmentKeys.TRANSACTION_ID_KEY);}}
then it'd probably work ...




> EJBClient user transaction is not propagated properly to the receiver
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7838
>                 URL: https://issues.jboss.org/browse/WFLY-7838
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: not relevant
>            Reporter: Mate Varga
>
> Setup:
> - WF 10.1.0.Final
> - two deployments, one EAR and one WAR
> - EAR exposes EJB methods (SFSBs and SLSBs)
> - WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
> Problem:
> The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
> - LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
> - EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
> - processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
> - later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
> - it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
> - it does not find the userTransaction there
> It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)