JPA 不能与在 HttpSession 中管理的 CDI 范围一起使用？答案

【问题标题】：JPA not usable with CDI scopes that are managed in HttpSession?JPA 不能与在 HttpSession 中管理的 CDI 范围一起使用？
【发布时间】：2011-12-18 14:06:00
【问题描述】：

属于最终绑定到 HttpSession 的范围的所有 CDI 托管 bean 都需要可序列化。这意味着所有属性都需要可序列化。 EntityManager 不是，虽然这似乎被认为是一个错误（here 和here （我不知道为什么它被关闭了。））。

这意味着，如果您想遵守规范，则不能从 CDI 范围（如 Session 或 Conversation）使用 JPA。

似乎 Java EE 几乎无法使用还是什么？

【问题讨论】：

标签： jakarta-ee jpa cdi entitymanager serializable

【解决方案1】：

你是对的：EntityManager 不可序列化，但你认为 CDI EG 没有注意到这一点 :-) 吗？

因此，当 CDI bean 被序列化（即 SFSB 的钝化）时，EntityManager 被认为是瞬态的，而不是。当 bean 被反序列化时，EntityManager 会自动重新注入到 Bean 中，因此它可以像以前一样工作。

问题是当您在 Bean 中使用扩展持久性上下文时。 Java EE 规范不支持此类 bean 的序列化。但是 Java EE 5 中的 Seam 2 等框架或 Java EE 6 中的 Seam3 Persistence 等 CDI 扩展为您提供了管理这些特殊用例的可能性。

【讨论】：

感谢您提供信息。我查看了 EJB 3.1 规范，它指出：'除非满足以下条件，否则容器不得钝化具有扩展持久性上下文的有状态会话 bean： 1. 持久性上下文中的所有实体都是可序列化的。 2. EntityManager 是可序列化的。不允许容器破坏有状态会话 bean 实例，因为它不满足这些要求。如果我理解正确的话，不能被钝化的SFSB必须保留在内存中。在 Session Scoped CDI bean 的情况下它看起来如何？
@Antoine，感谢您提供的信息，但您详细说明 Seam 3 究竟如何能够处理扩展持久性上下文的序列化或向我指出一些资源？
我没有在 Seam 3 中测试这种机制，但在 Seam 2 中它曾经可以工作，您可以在此处查看一些文档：docs.jboss.org/seam/latest/reference/en-US/html/…Seam 2 pojo 具有相同的功能。我会检查它是否已移植到 EJB 和 Simple CDI bean 的 Seam 3 持久性，并会及时通知您。
仅适用于专有功能，例如休眠状态。如果您不使用依赖范围的实体管理器，则使用 CDI 只注入一个代理并且该代理是可序列化的。实体管理器必须在请求范围内，否则一旦会话序列化，您就会遇到问题，例如在会话复制且没有专有功能的情况下。我想我在 MyFaces CODI 的 JPA 模块的文档中看到了这个提示。
它甚至不适用于 Hibernate 中的“专有功能”。在某些情况下，它会在不告诉你真相的情况下只是松散状态：/ Atm 你只能使用 entitymanager-per-request 模式。即使在这里，您也需要在 persistence.xml 中添加魔术属性以使实体可序列化（并且不要丢失有关其 _loaded 和 _dirty 标志的信息）。正如 Dar Whi 指出的那样：在 CDI 中，您应该使用生产者方法来创建 RequestScoped EntityManager。