为什么不只使用 CDI 支持的 bean（而不是 SFSB）来保存会话信息？答案

【问题标题】：Why not just use CDI backed bean (instead of SFSB) to hold Session information?为什么不只使用 CDI 支持的 bean（而不是 SFSB）来保存会话信息？
【发布时间】：2012-12-02 20:45:51
【问题描述】：

上下文

简单的 Java EE 6 (JBoss AS 7.1) CRUD Web 应用，使用 @Named 支持 bean，@SessionScope 个 JSF 页面：

问题

为什么在 CDI bean 上存储 HTTP 会话状态是个坏主意？例如，将购物车项目存储在此处。

SFSB 是为此而设计的，因为它们的会话状态，但我读到它们在practice 中并不容易使用。另外我认为另一个选择是 HttpSession 对象。

我也知道他们拥有的钝化/激活优势。

【问题讨论】：

标签： jsf jakarta-ee ejb cdi httpsession

【解决方案1】：

我认为您对用于 HTTP 会话的“会话”和用于与特定 bean 的会话（在本例中为有状态 bean）的会话感到困惑。

它们有不同的用途，但也有重叠。最初，带有 SFSB 的会话用于非 HTTP 远程客户端（Applet 和 Swing 应用程序）。在某种程度上，您可以说它是 HTTP 会话的 RMI 等价物。

当已经有可用的 HTTP 会话时，为此目的使用有状态会话 bean 是没有意义的，最好使用 HTTP 会话范围 bean。

有状态会话 bean 确实有它们的用途，例如它们能够容纳扩展的持久性上下文并可以保持例如（乐观）在事务之外打开锁。

在 Java EE 6 Web 应用程序中使用时，您通常希望为有状态会话 bean 分配一个 HTTP 会话范围。否则，即使 bean 有一个内部会话，它也不会连接到任何东西，而是连接到您用来与之通信的代理。

另见：

【讨论】：

uff... 你能给我更多关于扩展持久性上下文的信息吗？为 SFSB 分配一个 @SessionScope... 仅使用 CDI bean 有什么好处？
扩展的持久性上下文是一个 JPA 上下文，它不绑定（范围）到事务，而是绑定到有状态会话 bean 的生命周期。如需更详细的解释，您可以查看“Pro JPA 2”一书。
所以为了简单起见，如果不需要扩展持久上下文'，那么我应该远离 SFSB？
这可能有点太简单了，但是是的，扩展的持久性上下文是一个很大的用例。底线是;如果您需要 SFSB 的特定功能，请不要回避它，但不要将其“有状态”功能与 Web 应用程序中的一般状态概念混淆。 SFSB 绝不是存储 Web 应用程序状态的正常机制。
重述 Arjan：当除了状态保持功能之外，您还需要使用其他会话 bean 功能（如事务管理）时，您应该使用 SFSB（使用 JPA 扩展范围，SFSB 可以像使用SLSB) 或类似授权。如果您只需要多个请求状态，CDI 可能更容易。

【解决方案2】：

以下是 SFSB 的假定好处：

SFSB 是事务性的。
SFSB 可以被钝化/激活。
SFSB 启用扩展的持久性上下文。

为此付出的代价是异常方案更复杂（回滚、非回滚异常等）、生命周期以及结果调试。

通常，您不需要钝化/激活。为了使设计具有可扩展性，请尽可能少地存储在内存中。通常，也不需要扩展持久性上下文（尽管它们有其用途）。

但是，请求必须以事务方式处理。但是你不需要SFSB。您可以自己处理错误和恢复，以确保您的 HttpSession 是一致的。不过，请确保您使用事务来访问您的后端！

【讨论】：