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