[
https://issues.jboss.org/browse/WFLY-4333?page=com.atlassian.jira.plugin....
]
Richard Achmatowicz edited comment on WFLY-4333 at 7/14/15 3:22 PM:
--------------------------------------------------------------------
When is a EJB bean stateless?
"A stateless session bean does not maintain a conversational state with the client.
When a client invokes the methods of a stateless bean, the bean’s instance variables may
contain a state specific to that client but only for the duration of the invocation. When
the method is finished, the client-specific state should not be retained.
Clients may, however, change the state of instance variables in pooled stateless beans,
and this state is held over to the next invocation of the pooled stateless bean. Except
during method invocation, all instances of a stateless bean are equivalent, allowing the
EJB container to assign an instance to any client. That is, the state of a stateless
session bean should apply across all clients."
How is the Entity being managed by the SLSB on the server side? I suppose the Entity
looked up anew on each invocation? Otherwise the state of the bean would not be the same
after each invocation.
was (Author: rachmato):
When is a EJB bean stateless?
"A stateless session bean does not maintain a conversational state with the client.
When a client invokes the methods of a stateless bean, the bean’s instance variables may
contain a state specific to that client but only for the duration of the invocation. When
the method is finished, the client-specific state should not be retained.
Clients may, however, change the state of instance variables in pooled stateless beans,
and this state is held over to the next invocation of the pooled stateless bean. Except
during method invocation, all instances of a stateless bean are equivalent, allowing the
EJB container to assign an instance to any client. That is, the state of a stateless
session bean should apply across all clients."
How is the Entity being managed by the SLSB on the server side?
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)