[jboss-jira] [JBoss JIRA] (WFLY-4333) Transaction must be sticky to ensure consistency for EJB remote invocation with JPA

[Wolf-Dieter Fink (JIRA)]

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

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