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

[David Lloyd (JIRA)]

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

David Lloyd commented on WFLY-4333:
-----------------------------------

For WildFly 11 (most likely), we already are or will definitely be doing the following:

* Adding a client configuration switch to optionally disable transaction propagation
* Ensure that UserTransactions can always be looked up in JNDI
* Provide a simpler mechanism by which transaction stickiness can be done (e.g. interceptor, storing stickiness data on the transaction object itself)
* Ensure that retry is addressed
** ...in the current {{NoSuchEJBException}} case
** ...in light of the new {{@Idempotent}} annotation


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