当客户端返回时，有状态会话 Bean 如何恢复状态？
如果有状态会话 bean 将要钝化，其状态将被写入硬盘，然后 bean 实例将被释放以服务其他请求（至少这是我的理解）。当同一个客户端再次处于活动状态时，Bean实例将从硬盘读取状态以重新获得状态。但是 bean 实例如何知道它必须为哪个客户端读取哪个文件来维护状态呢？
我对 J2EE 很陌生，所以如果我提出一个非常幼稚的疑问，请原谅我。如果我需要了解任何其他主题才能理解这一点，请为我指出正确的方向。
If the stateful session bean is going to passivate, its state is written to harddisk and then the bean instance will be freed to serve other request (at least this is my understanding). When the same client is active again, bean instance will read the state from hard disk to regain the state. But how the bean instance knows that for which client which file it has to read to maintain the state?
I am very new to J2EE, so please pardon me if I am asking a very naive doubt. If I need to know any other topic to understand this, please point me in the right direction.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最好将有状态会话 Bean (SfSB) 想象为非常接近普通 Java 类的实例。您查找（或注入）SfSB 的实例，容器将为您创建一个实例并返回该实例。然后，您可以像使用任何其他 Java 实例一样使用该实例。
这意味着您可以将实例存储到会话中，将其序列化到磁盘等。
详细信息是您正在使用的实例实际上是实际的底层 SfSB 实例的代理。这并不是真正的 SfSB 本身。
当您在本地代理上调用 bean 时，容器会为您将该 bean 显化到内存中。 bean 的钝化和激活是在幕后为您完成的（尽管您可以通过 bean 生命周期进入该过程）。
容器查找钝化 SfSB 所需的任何信息都存储在您正在使用的代理中，但这对您来说是不透明的。你不用担心。
因此，在典型的基于 Web 的场景中，生命周期是您获取 Bean 实例，将其存储在 Web 会话中，然后像平常一样使用它。如果容器决定需要钝化您的 bean 以腾出空间或其他什么，它会自动为您钝化它。当您的用户返回时，您的应用程序从 Web 会话中提取实例并进行调用。那时，如果 bean 被钝化，容器将再次自动为您激活 bean。整个机制依赖于容器，但对您来说是透明的。您要记住的重要一点是，您必须保留从容器中获取的 SfSB，就像保留任何 java 对象一样。
最后需要注意的是，如果您允许 SfSB 钝化时间过长，容器会自动为您删除它。
It's best to visualize a Stateful Session Bean (SfSB) as very close to an instance of a normal Java class. You look up (or inject) an instance of a SfSB, and the container will create one for you and return the instance. You then work with that instance like you would any other Java instance.
That means that you can store the instance in to a Session, serialize it to disk, etc.
The detail is that the instance you are working with is actually a proxy to the actual, underlying SfSB instance. It's not the actual SfSB itself.
When you make a call on your local proxy to the bean, it is the containers job to manifest that bean in to memory for you. The passivation and activation of the bean is done behind the scenes for you (though you can tap in to the process through the beans lifecycle).
Any information that the container needs to find the passivated SfSB is stored in the proxy that you're working with, but this is opaque to you. You needn't worry about it.
So, in a typical web based scenario, the life cycle would be that you get your bean instance, store it in a web session, and then simply use it like normal. If the container decides it needs to passivate your bean to make room or whatever, it will passivate it automatically for you. When your user returns, your app pulls the instance from the web session, and makes its calls. At that time, if the bean is passivated, the container will activate the bean for you, again automatically. This entire mechanism is dependent on the container, yet transparent to you. The important thing for you to recall is that you must hang on to SfSB that you get from the container, like you would any java object.
The final caveat is that if you allow a SfSB to be passivated for too long, the container will automatically delete it for you.