[
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
Transaction must be sticky to ensure consistency for EJB remote
invocation with JPA
-----------------------------------------------------------------------------------
Key: WFLY-4333
URL:
https://issues.jboss.org/browse/WFLY-4333
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Wolf-Dieter Fink
Assignee: Tomasz Adamski
Priority: Critical
Labels: ejb, transaction
If an application inside of a server uses standard JavaEE persistence JPA, the current
implementation include a local 1. level cache which might end in inconsistent reads within
the same (uncommited) transaction.
There are two reasons
- JPA must not flush changes to an entity until commit
- The 1. level cache might not read from the persistence if the entity is already loaded
in a transaction
Therefore the server to server invocations of EJB's need to be sticky to one node
during a transaction. The granularity must be the application.
It might be worth to use already known nodes for other applications as well.
The stickyness should be enabled automatically if a transaction is active and
distributed, which is the default within the current implementation, and use the
loadbalancing policy if no transaction is active.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)