CDI、有状态会话 bean、无状态会话 bean、pojo 和不同范围之间的关系

Question

我正在学习 j2ee，如果问题显得非常基础，请见谅。

在httpsession中，会话ID存储在客户端，与之关联的数据存储在服务器端。

当有状态会话 bean 与 Web 客户端交互时，浏览器向 Java EE Web 应用程序发出初始请求，它会获得一个 JSESSIONID，服务器可以将其与特定的 HTTPSession 实例相关联。通过保持这个 JSESSIONID，浏览器可以向它提供每个后续请求，这将激活相同的 http 会话服务器端。 参考： Using a Stateful Session Bean to track an user's session

现在当我在 sfb 上使用 CDI @SessionScoped 时，这是否意味着该 SFB 或 EJB 容器(?) 只会返回 JSESSIONID将存储另一个 服务器端的sfb副本？ (session.setAttribute(SFB-Another-Reference))

现在，当我在 sfb 上使用 CDI @RequestScoped 时，它是否无用，因为 SFB 一直存在到会话中？

现在当我在 slb 上使用 CDI @SessionScoped 时，使用 @SessionScoped 是否无用，因为 slb 仅用于方法调用？

现在我在 POJO 上使用 CDI @SessionScoped 这是否意味着 EJB 容器 (?) 将 pojo 存储在会话中。 (session.setAttribute(POJO))

CDI 可以区分 SFB 、SLB 和 POJO 吗？

Answer 1

现在，当我在 sfb 上使用 CDI @SessionScoped 时，这是否意味着将为该 SFB 或 EJB 容器返回 JSESSIONID（？）将在服务器端存储另一个 sfb 副本？

JSESSIONID 与 http 会话有关，与任何 EJB（无状态或有状态）无关。当您使用@SessionScoped 时，您的 sfb 将通过 CDI 与您的 http 会话相关联。

现在，当我在 sfb 上使用 CDI @RequestScoped 时，它会因为 SFB 一直存在到会话而无用吗？

不，由于其他原因，它没有用，因为每个请求都会创建新的有状态 bean，这实际上打破了有状态 bean 的整个想法，它应该在请求之间存储状态。

现在当我在 slb 上使用 CDI @SessionScoped 时使用它没用吗 @SessionScoped 因为 slb 仅用于方法调用？

或多或少是的。一些 CDI 框架（例如 OWB）甚至不允许这样做，并且只允许 @Dependent 范围。 SLB 实际上寿​​命更长，但由于它不存储任何状态，因此它的实例可以被许多客户端池化和使用。

现在当我在 POJO 上使用 CDI @SessionScoped 时，这是否意味着 EJB 容器（？）将 pojo 存储在会话中。 (session.setAttribute(POJO))

那个POJO是通过CDI框架与http session相关联的，并不是直接作为属性存储在session中的。

CDI 可以区分 SFB 、SLB 和 POJO 吗？

是的，CDI 容器可以区分这些并区别对待它们，例如类型可见性，允许范围。例如规范片段：

无状态会话 bean 必须属于 @Dependent 伪作用域。一种 单例 bean 必须属于 @ApplicationScoped 范围或 到@Dependent 伪作用域。如果会话 bean 指定了非法 作用域，容器自动检测问题并处理 作为定义错误。有状态会话 bean 可以有任何范围。