[ https://issues.jboss.org/browse/WFLY-4333?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink edited comment on WFLY-4333 at 7/15/15 5:26 AM: ----------------------------------------------------------------- An example (without JPA) for the stickyness can be found here https://github.com/wfink/jboss-eap-quickstarts/tree/TxStickySelector_expe... in the ejb-multi-server quickstart. A custom NodeSelector is implemented to provide the stickyness. This behaviour should be implemented without the need of a customized NodeSelector. The following options should be considered: - No Transaction propagation across remote invocations This is the previous behaviour (before AS7/WildFly) and will ensure that applications which rely on this (use the default JTA in AS4/5 not JTS) can be migrated without effort - Transaction propagation No TxSticky This is the current (only) behaviour - Tx propagation, TxStick for application mean that all EJB invocations related to the same "EAR/module/distinct" must use the same node ==> this is the most convenient behaviour and should be the new default - Tx propagation, hard TxStick after one invocation ALL other invocations need to be sticky to exact this node -> drawback is that if one application is not deployed here (no symetric deployment) the Tx must fail! The node selection should prefer: - local instance if the app is available - an already involved node if possible and the app is available) - the (customized) node selector should not be invoked in this case! In any case the Tx will fail if Stickyness is enabled and one of the used nodes fail until the Tx is active, it is not possible to have a failover during the transaction was (Author: wdfink): An example (without JPA) for the stickyness can be found here https://github.com/wfink/jboss-eap-quickstarts/tree/TxStickySelector_expe... in the ejb-multi-server quickstart. A custom NodeSelector is implemented to provide the stickyness. This behaviour should be implemented without the need of a customized NodeSelector. The following options should be considered: - No Transaction propagation across remote invocations This is the previous behaviour (before AS7/WildFly) and will ensure that applications which rely on this (use the default JTA in AS4/5 not JTS) can be migrated without effort - Transaction propagation No TxSticky This is the current (only) behaviour - Tx propagation, TxStick for application mean that all EJB invocations related to the same "EAR/module/distinct" must use the same node ==> this is the most convenient behaviour and should be the new default - Tx propagation, hard TxStick after one invocation ALL other invocations need to be sticky to exact this node -> drawback is that if one application is not deployed here (no symetric deployment) the Tx must fail! In any case the Tx will fail if Stickyness is enabled and one of the used nodes fail until the Tx is active, it is not possible to have a failover during the transaction -- This message was sent by Atlassian JIRA (v6.3.15#6346)