December 2016 - jboss-jira - Jboss List Archives

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

by Mate Varga (JIRA)

[ https://issues.jboss.org/browse/WFLY-7838?page=com.atlassian.jira.plugin.... ] 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. In other words, if this line: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... would be `final TransactionID transactionID = (TransactionID) context.getContextData().get(AttachmentKeys.TRANSACTION_ID_KEY);` then it'd probably work ... 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. > 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. > In other words, if this line: > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... > would be > `final TransactionID transactionID = (TransactionID) context.getContextData().get(AttachmentKeys.TRANSACTION_ID_KEY);` > then it'd probably work ... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

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

by Mate Varga (JIRA)

Mate Varga created WFLY-7838: -------------------------------- Summary: 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)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7836) Upgrade wildfly-arquillian to 2.0.2.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7836?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7836: --------------------------------- Description: Bugfix release. Changelog: https://issues.jboss.org/issues/?jql=project%20%3D%20WFARQ%20AND%20fixVer... was:Bugfix release. > Upgrade wildfly-arquillian to 2.0.2.Final > ----------------------------------------- > > Key: WFLY-7836 > URL: https://issues.jboss.org/browse/WFLY-7836 > Project: WildFly > Issue Type: Component Upgrade > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: James Perkins > Fix For: 11.0.0.Alpha1 > > > Bugfix release. > Changelog: > https://issues.jboss.org/issues/?jql=project%20%3D%20WFARQ%20AND%20fixVer... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7836) Upgrade wildfly-arquillian to 2.0.2.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7836?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7836: --------------------------------- Component/s: Test Suite > Upgrade wildfly-arquillian to 2.0.2.Final > ----------------------------------------- > > Key: WFLY-7836 > URL: https://issues.jboss.org/browse/WFLY-7836 > Project: WildFly > Issue Type: Component Upgrade > Components: Test Suite > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: James Perkins > Fix For: 11.0.0.Alpha1 > > > Bugfix release. > Changelog: > https://issues.jboss.org/issues/?jql=project%20%3D%20WFARQ%20AND%20fixVer... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7837) Upgrade wildfly-arquillian to 2.0.2.Final

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7837: ------------------------------------ Summary: Upgrade wildfly-arquillian to 2.0.2.Final Key: WFLY-7837 URL: https://issues.jboss.org/browse/WFLY-7837 Project: WildFly Issue Type: Component Upgrade Components: Test Suite Affects Versions: 10.1.0.Final Reporter: Radoslav Husar Assignee: James Perkins Priority: Critical Fix For: 11.0.0.Alpha1 Bugfix release. Changelog: https://issues.jboss.org/issues/?jql=project%20%3D%20WFARQ%20AND%20fixVer... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7836) Upgrade wildfly-arquillian to 2.0.2.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7836?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7836: --------------------------------- Priority: Critical (was: Major) > Upgrade wildfly-arquillian to 2.0.2.Final > ----------------------------------------- > > Key: WFLY-7836 > URL: https://issues.jboss.org/browse/WFLY-7836 > Project: WildFly > Issue Type: Component Upgrade > Components: Test Suite > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: James Perkins > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > Bugfix release. > Changelog: > https://issues.jboss.org/issues/?jql=project%20%3D%20WFARQ%20AND%20fixVer... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7836) Upgrade wildfly-arquillian to 2.0.2.Final

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7836: ------------------------------------ Summary: Upgrade wildfly-arquillian to 2.0.2.Final Key: WFLY-7836 URL: https://issues.jboss.org/browse/WFLY-7836 Project: WildFly Issue Type: Component Upgrade Affects Versions: 10.1.0.Final Reporter: Radoslav Husar Assignee: James Perkins Fix For: 11.0.0.Alpha1 Bugfix release. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7799) Failover targets should be chosen deterministically

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7799?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7799: --------------------------------- Affects Version/s: 10.1.0.Final > Failover targets should be chosen deterministically > --------------------------------------------------- > > Key: WFLY-7799 > URL: https://issues.jboss.org/browse/WFLY-7799 > Project: WildFly > Issue Type: Feature Request > Components: mod_cluster, Web (Undertow) > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 11.0.0.Alpha1 > > > See UNDERTOW-898. > This issue is to track inclusion of the feature in WF and corresponding integration code. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7799) Failover targets should be chosen deterministically

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7799?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7799: --------------------------------- Fix Version/s: 11.0.0.Alpha1 > Failover targets should be chosen deterministically > --------------------------------------------------- > > Key: WFLY-7799 > URL: https://issues.jboss.org/browse/WFLY-7799 > Project: WildFly > Issue Type: Feature Request > Components: mod_cluster, Web (Undertow) > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 11.0.0.Alpha1 > > > See UNDERTOW-898. > This issue is to track inclusion of the feature in WF and corresponding integration code. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7799) Failover targets should be chosen deterministically

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7799?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7799: --------------------------------- Affects Version/s: 10.0.0.Final > Failover targets should be chosen deterministically > --------------------------------------------------- > > Key: WFLY-7799 > URL: https://issues.jboss.org/browse/WFLY-7799 > Project: WildFly > Issue Type: Feature Request > Components: mod_cluster, Web (Undertow) > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 11.0.0.Alpha1 > > > See UNDERTOW-898. > This issue is to track inclusion of the feature in WF and corresponding integration code. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2016