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

[Richard Achmatowicz (JIRA)]

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

Richard Achmatowicz commented on WFLY-4333:
-------------------------------------------

Here is the scenario discussed in the call which illustrates the problem (Wolf, Tomasz, Richard):

Suppose a server client deployment has a bean which makes multiple invocations on a remote clustered SLSB via a remote outbound connection. 
By default, SLSB invocations will be load balanced between the two nodes of the cluster. 
In addition, suppose the method on the bean which makes these remote clustered SLSB invocations is transactional and part of a managed transaction context controller by the server.  
So the method called from the server client may look like:
{noformat}
// lookup SLSB
MyRemoteSLSB slsb = ctx.lookp("...") 

@TransactionAttribute(REQUIRES)
void makeInvocations() {
  slsb.invocation1();
  // do stuff 
  slsb.invocation2();
  // do stuff
  slsb.invocation3() ;
}
{noformat}

Now assume that the remote SLSB has methods which create, access and update an Entity bean to store persistent state. Invocation1() reads the state, invocation2() updates the state and invocation3() reads the state.

Because SLSBs are by default load balanced, this will result in invocation1() an invocation3() being sent to node A, and invocation2() being sent to node B. 

The problem as stated is that because the method, makeInvocations(), in which those remote invocations are made, does not commit until all three invocations have completed, the persistent state seen by all three invocations will not be as expected (in other words, each subsequent request will not see the effect of the one that came before it). 



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