sessionscoped 托管 Bean 与有状态 EJB
如果我有一个 @SessionScoped 的 @ManagedBean，为什么我要使用 @Stateful EJB？我之前用它来购物车和维护会话状态，但由于托管 bean 将在用户会话期间保留，我可以在那里存储状态，然后调用 SLSB 进行业务逻辑。这是正确的吗？如果是，那么有状态 ejb 将留给更具体的应用程序，例如当您需要事务等时？
If I have a @ManagedBean that's @SessionScoped, why would I use a @Stateful EJB? I used it before for shopping carts and maintaining a conversational state, but since a managed bean will be kept during the user session I can store state there, then call SLSB for bussiness logic. Is that correct? If it is, then stateful ejbs will be left for more specific applications such as when you need transactions etc?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
无状态会话 bean 通常可用于解决许多业务问题。
有状态并不一定意味着只有远程服务器保持状态，尽管这肯定是选项之一。远程 Swing 客户端可以首先将一堆数据发送到有状态会话 Bean，保留存根，然后发送一些操作这些数据的命令。这使客户端不必每次都发送相同（大量）的数据。
在远程用例中，它确实在某种程度上反映了使用 Web 客户端（浏览器）时 HTTP 会话的使用情况。主要区别在于，这里的会话是针对每个 bean 的，而对于 HTTP 会话，会话是由许多 bean 共享的范围。由于HTTP 会话基于cookie，并且cookie 对于整个浏览器的域来说是全局的，因此HTTP 会话不能直接支持来自同一客户端的多个会话（例如每个选项卡或每个窗口）。这对于有状态会话 bean 来说是微不足道的。
然而...
远程 Swing 客户端与远程 EJB 的对话并不常见。
在您的问题中描述的上下文中，您通常会使用本地 EJB，并且会将大部分状态存储在 HTTP 会话中（小心共享！），现在存储在视图范围或会话范围中。
那么，最后，在这种情况下何时使用有状态会话 Bean？
一个重要的用例是
JPA中的扩展持久性上下文。通常，对于事务范围的实体管理器，当实体跨越 EJB 方法调用的事务边界时，它将被分离。如果您想（乐观地）在用户交互之间锁定实体，这是不可取的。你会失去锁。使用扩展的持久性上下文，当您从有状态会话 bean 的调用返回时，实体保持附加状态并且锁定有效。这对于预览功能非常有用，可以确保在预览后没有其他人对实体进行任何更改。或者确实对于购物车，您希望确保在一段时间内购物车中的商品无法出售给其他任何人。
Very often stateless session beans can be used for a lot of business problems.
Stateful does not necessarily means only a remote server keeps state, although this is certainly one of the options. A remote Swing client could first send a bunch of data to a stateful session bean, hold on to the stub and then subsequently send some commands that operate on this data. This saves the client from having to send the same (large amount of) data each and every time.
In the remote use case, it indeed somewhat mirrors the usage of the HTTP session when web clients (browsers) are used. The major difference is that the session is per bean here, while with the HTTP session, the session is a scope shared by many beans. Since the HTTP session is based on cookies, and cookies are global for a domain for the entire browser, the HTTP session can not directly support multiple sessions from the same client (e.g. per tab or per window). This is trivial with stateful session beans.
However...
Remote Swing clients talking to remote EJBs are not that common.
In the context you described in your question, you will typically use local EJBs and you will store most state in the HTTP session (be careful with sharing!) and these days in the view scope or conversation scope.
So, finally, when to use stateful session beans in this scenario?
One important use case is the
extended persistence contextinJPA. Normally with a transaction scoped entity manager, when an entity crosses the transactional boundary of an EJB method call it will be detached. If you want to (optimistically) lock an entity between user interactions, this is undesirable. You'll lose the lock.With an extended persistence context, the entity remains attached and the locks valid when you return from a call to the stateful session bean. This is very useful for preview functionality to assure that nobody else has made any changes to the entity when you okay after the preview. Or indeed for a shopping cart where you want to assure that for some time the item can't be sold to anyone else while in the cart.