[
https://issues.jboss.org/browse/WFLY-4333?page=com.atlassian.jira.plugin....
]
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)