EJB中下一次调用的无状态bean的实例变量的状态如何？ [英] how is state of instance variables of a stateless bean preserved for next invocation in EJB?

问题描述

我正在阅读 Java EE7文档这就是对无状态bean的说法。我对以下粗体下面的陈述的含义感到困惑

无状态会话bean与客户端不保持会话状态。当客户端调用无状态bean的方法时，bean的实例变量可能包含特定于该客户端的状态，但仅在调用期间。方法完成后，不应保留特定于客户端的状态。然而，客户端可能会更改池化无状态bean中的实例变量的状态，并将此状态保留到下一次调用池状态的无状态bean。除了方法调用之外，无状态bean的所有实例是等效的，允许EJB容器为任何客户端分配一个实例。也就是说，无状态会话bean的状态应该适用于所有客户端。

但是从这篇文章中，
无状态会话bean中的实例变量

无状态会话bean是一个没有关联会话状态的对象，但可能具有实例状态。它不允许并发访问该bean。实例变量的内容不能保证在方法调用之间保留。无状态会话bean的所有实例应该被客户端认为是相同的。

我觉得这里有矛盾。文档声称（从我的理解），实例变量状态在下一次调用中被保留，而后者声明不保证状态被保留。

请解释

PS：我读过这篇文章：但是我没有把握答案

无状态会话bean中的实例变量

编辑从上面的SO发布

无状态会话Bean ）不绑定到一个客户端，并且不保证一个客户端可以通过每个方法调用来获取相同的实例（一些容器可以使用每个方法调用会话来创建和销毁bean，这是一个实现特定的决定，但实例通常是池 - 我不提集群环境）。换句话说，虽然无状态bean可能有实例变量，但是这些字段不是一个客户端特有的，所以不要在远程调用之间依赖它们。

解决方案

1. SLSB通常以倍数创建，并存放在池中。因此，对于EJB UserDataService ，将创建​​并合并多个实例




2. 当客户端请求 UserDataService 的服务，容器将提供其中一个池化实例。 任何一个。当两个客户端请求同一EJB的服务时，将有两个单独的实例提供




3. 当客户端使用SLSB完成，正在使用的实例通常返回到池，不被销毁 。这意味着在容器启动时创建的相同的唯一EJB对象在容器的正常运行时间内可以相当可想而知地存在堆上。重要的是：容器首次将EJB投入使用时，创建和合并的相同的SLSB在容器的正常运行时间内保持活着。


（3）意味着如果（2）中的客户端在从池中获取的EJB的实例上设置任何变量，并将EJB放回到池中，那么获取的下一个客户端那个非常实例将能够看到对EJB状态的改变（回想一下，在池中有一个固定数量的EJB实例，并且它们在请求服务的各种客户端之间循环）。 p>


4. 不能保证请求客户端的 UserDataService 的具体实例。不能保证（2）中的客户端将获得与该EJB的两个单独请求相同的 UserDataService 实例。这就是没有会话状态的含义。 您不能保证通过多次调用与该EJB的同一实例进行通话。这并不意味着EJB在中间请求中被破坏，只是在循环过程中，您无法确定您的客户端将与...相关的实例。

I am reading Java EE7 documentation and here is what it says for stateless bean. I am confused with what is meant by the statement marked in bold below

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.

However from this post, instance variables in stateless session beans

A stateless session bean is an object that does not have an associated conversational state, but may have instance state. It does not allow concurrent access to the bean. The contents of instance variables are not guaranteed to be preserved across method calls. All instances of a stateless session bean should be considered identical by the client.

I feel that there is a contradiction here. The docs claim (from my understanding) that the instance variable state is preserved across next invocations while the latter post claims there is no guarantee that the state is preserved.

please explain

P.S: I did read this post: but I did not grasp the answer

instance variables in stateless session beans

EDIT form the SO post above

Stateless Session Beans (SLSB) are not tied to one client and there is no guarantee for one client to get the same instance with each method invocation (some containers may create and destroy beans with each method invocation session, this is an implementation-specific decision, but instances are typically pooled - and I don't mention clustered environments). In other words, although stateless beans may have instance variables, these fields are not specific to one client, so don't rely on them between remote calls.

解决方案

1. SLSBs are usually created in multiples and are stashed in a pool. So for an EJB UserDataService, there'll be a number of instances created and pooled

2. When a client requests the services of UserDataService, the container is going to serve one of the pooled instances. Any one. When two clients request the services of the same EJB, there will be two separate instances served

3. When a client is done with an SLSB, the instance that was in use is usually returned to the pool, not destroyed. What this means is that the same unique EJB objects that were created on container startup could quite conceivably live on the heap for the duration of the container's uptime. That bears repeating: The same SLSBs that were created and pooled when the container first put the EJB into service, are kept alive through the uptime of the container

4. What (3) means is that if a client in (2) set any variables on the instance of the EJB that it acquired from the pool and that EJB is put back into the pool, the next client that acquires that very instance will be able to see the change made to the state of that EJB (Recall that there is a (sort of) fixed number of instances of the EJBs in the pool and they are cycled among various clients requesting service).

5. There's no guarantee which specific instance of UserDataService a requesting client will get. There's no guarantee that the client in (2) will get the same instance of UserDataService on two separate requests for that EJB. This is what is meant by no conversational state. You're not guaranteed to be talking to the same instance of that EJB over multiple invocations. This doesn't mean that the EJBs are destroyed mid request, just that in the process of cycling, you cannot be sure of what instance your client will be relating with

这篇关于EJB中下一次调用的无状态bean的实例变量的状态如何？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！