[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=13089453#comment-13089453 ] 

Richard Achmatowicz edited comment on WFLY-4333 at 7/14/15 3:48 PM:
--------------------------------------------------------------------

The issue seems to be as Wolf stated that, for this particular atypical SLSB deployment, if multiple invocations on the bean occur within the same transaction, they need to be able to be tied to one node for the duration of the transaction.

My understanding is that under normal circumstances, what will happen in the above scenario is as follows:
- the server client transaction T will begin
- invocation1() will participate in the transaction T by propagating the transaction id for T with the invocation; this will result in a corresponding transaction being created on the server A, the work being completed within the scope of that server side transaction, and the the server side transaction being suspended when the response is returned;  
- invocation2() will participate in the transaction T by propagating the transaction id for T with the invocation; this will result in a corresponding transaction being created on the server B, the work being completed within the scope of that server side transaction, and the the server side transaction being suspended when the response is returned;  
- invocation3() will participate in the transaction T by propagating the transaction id for T with the invocation; this will result in a corresponding transaction being resumed on the server A, the work being completed within the scope of that server side transaction, and the the server side transaction being suspended when the response is returned;  
- when transaction T does a commit or a rollback, the transaction manager for T causes EJBClient protocol messages to be sent to each server with the id for transaction T telling them to commit or rollback, and the transaction completes.

 



was (Author: rachmato):
The issue seems to be as Wolf stated that, for this particular atypical SLSB deployment, if multiple invocations on the bean occur within the same transaction, they need to be able to be tied to one node for the duration of the transaction.

My understanding is that under normal circumstances, what will happen in the above scenario is as follows:
- the server client transaction T will begin
- invocation1() will participate in the transaction T by propagating the transaction id for T with the invocation; this will result in a corresponding transaction being created on the server A, the work being completed within the scope of that server side transaction, and the the server side transaction being suspended;  
- invocation2() will participate in the transaction T by propagating the transaction id for T with the invocation; this will result in a corresponding transaction being created on the server B, the work being completed within the scope of that server side transaction, and the the server side transaction being suspended;  
- invocation3() will participate in the transaction T by propagating the transaction id for T with the invocation; this will result in a corresponding transaction being resumed on the server A, the work being completed within the scope of that server side transaction, and the the server side transaction being suspended;  
- finally when transaction T does commit or rollback, EJBClient protocol messages are sent to each server with the id for transaction T telling them to commit or rollback.
 


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