jsf - session 范围的托管 bean 与有状态的 ejb

Question

如果我有一个 @ManagedBean那是 @SessionScoped ，我为什么要使用 @Stateful EJB？我之前将它用于购物车和维护对话状态，但由于在用户 session 期间将保留托管 bean，我可以在那里存储状态，然后调用 SLSB 进行业务逻辑。那是对的吗？如果是，那么有状态的 ejb 将留给更具体的应用程序，例如当您需要事务等时？

Answer 1

通常无状态 session bean 可用于解决许多业务问题。

有状态并不一定意味着只有远程服务器保持状态，尽管这当然是选项之一。远程 Swing 客户端可以首先向有状态 session bean 发送一堆数据，保留 stub ，然后发送一些对这些数据进行操作的命令。这使客户端不必每次都发送相同的(大量)数据。

在远程用例中，它确实在某种程度上反射(reflect)了使用 Web 客户端(浏览器)时 HTTP session 的使用情况。主要区别在于这里的 session 是每个 bean 的，而对于 HTTP session ， session 是由许多 bean 共享的范围。由于 HTTP session 基于 cookie，并且 cookie 对于整个浏览器的域是全局的，因此 HTTP session 不能直接支持来自同一客户端的多个 session (例如，每个选项卡或每个窗口)。这对于有状态 session bean 来说是微不足道的。

不过……

与远程 EJB 通信的远程 Swing 客户端并不常见。

在您在问题中描述的上下文中，您通常会使用本地 EJB，并将大多数状态存储在 HTTP session 中(共享时要小心!)，现在存储在 View 范围或对话范围中。

那么，最后，在这种情况下何时使用有状态 session bean？

一个重要的用例是 extended persistence context在 JPA .通常对于事务范围的实体管理器，当一个实体跨越 EJB 方法调用的事务边界时，它将被分离。如果您想(乐观地)在用户交互之间锁定实体，这是不可取的。你会失去锁。

使用扩展的持久性上下文，当您从对有状态 session bean 的调用返回时，实体保持附加状态并且锁定有效。这对于预览功能非常有用，可以确保在预览后您没问题时没有其他人对实体进行任何更改。或者确实对于购物车，您要确保在一段时间内该物品不能在购物车中出售给其他任何人。