如果我有一个@ManagedBean 即@SessionScoped，我为什么要使用@Stateful EJB？我之前将它用于购物车并维护会话状态，但由于在用户会话期间将保留托管 bean，因此我可以将状态存储在那里，然后调用 SLSB 进行业务逻辑。那是对的吗？如果是，那么有状态的 ejb 将留给更具体的应用程序，例如何时需要事务等？
【问题讨论】：
标签： jsf ejb managed-bean stateful-session-bean
无状态会话 bean 通常可用于解决很多业务问题。
有状态并不一定意味着只有一个远程服务器保持状态，尽管这肯定是选项之一。远程 Swing 客户端可以首先将一堆数据发送到有状态会话 bean，保留存根，然后发送一些对这些数据进行操作的命令。这使客户端不必每次都发送相同（大量）数据。
在远程用例中，它确实在某种程度上反映了使用 Web 客户端（浏览器）时 HTTP 会话的使用。主要区别在于这里的会话是每个 bean，而对于 HTTP 会话，会话是许多 bean 共享的范围。由于 HTTP 会话基于 cookie，并且 cookie 对整个浏览器的域都是全局的，因此 HTTP 会话不能直接支持来自同一客户端的多个会话（例如，每个选项卡或每个窗口）。这对于有状态会话 bean 来说是微不足道的。
不过……
与远程 EJB 通信的远程 Swing 客户端并不常见。
在您在问题中描述的上下文中，您通常会使用本地 EJB，并且您会将大部分状态存储在 HTTP 会话中（小心共享！），而这些天在视图范围或会话范围中。
那么，最后，在这种情况下何时使用有状态会话 bean？
一个重要的用例是JPA 中的extended persistence context。通常使用事务范围的实体管理器，当实体跨越 EJB 方法调用的事务边界时，它将被分离。如果您想（乐观地）在用户交互之间锁定实体，这是不可取的。你会失去锁。
使用扩展的持久性上下文，当您从对有状态会话 bean 的调用返回时，实体保持连接状态并且锁有效。这对于预览功能非常有用，可以确保在预览后没有任何其他人对实体进行任何更改。或者确实对于购物车，您希望确保在一段时间内该商品在购物车中时不能出售给其他任何人。
【讨论】：