[
https://issues.jboss.org/browse/WFLY-4333?page=com.atlassian.jira.plugin....
]
Richard Achmatowicz edited comment on WFLY-4333 at 7/14/15 3:46 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;
- 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.
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.
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)