JPA：扩展持久性上下文与分离实体

如何解决JPA：扩展持久性上下文与分离实体

| 使用JPA来实现跨越几个http请求的业务交易似乎有两种模式： 每个请求的实体经理与分离的实体 扩展的持久性上下文 这些模式的各自优点是什么？什么时候应该首选？ 到目前为止，我想到了： 扩展的持久性上下文可确保对象身份等同于数据库身份，从而简化了编程模型，并可能消除了对实体实施相等的需求 分离的实体比扩展的持久性上下文需要更少的内存，因为持久性上下文还必须存储实体的先前状态以进行更改检测 不再引用的独立实体有资格进行垃圾收集；持久对象必须首先明确分离 但是，我对JPA没有任何实践经验，所以我确信我已经错过了一些重要的事情，因此，这个问题就没有了。 在某些情况下：我们打算使用Hibernate 3.6支持的JPA 2.0。 编辑：我们的视图技术是EJB 3.1容器中的JSF 2.0，带有CDI以及可能的Seam 3。     

解决方法

        好吧，我可以列举在Web环境中尝试使用扩展的持久性上下文的挑战。有些事情还取决于您的视图技术是什么，以及它是否是绑定实体或视图级别的中间人。 EntityManager不是线程安全的。 每个用户会话不需要一个。 每个用户会话需要一个 浏览器标签。 当出现异常时 EntityManager，它被认为 无效，需要关闭 更换。如果您打算 编写自己的框架扩展 为了管理延长的生命周期， 实施此需要 防弹。通常在 每个请求的EM设置例外 转到某种错误页面， 然后加载下一页创建一个 无论如何都会像以前一样新 有。 对象平等将不会 100％自动安全。如上， 异常可能已失效 上下文中较早加载的对象 与之相关，所以一个 现在将不相等。使那个 假设还假设一个极端 高水平的技能和 了解JPA的工作原理，以及 EM在 开发人员使用它。例如。， 意外使用合并时 不需要的将返回新的 不满足的对象== 与其领域相同 前任。 （处理合并像 SQL \'update \'非常常见 JPA noobie尤其是“错误” 因为这只是绝大部分 时间流逝。） 如果您使用的是查看技术 绑定POJO（例如SpringMVC） 并且您打算绑定网络表单 数据直接存储到您的实体中， 您很快就会遇到麻烦。 对附属实体的更改将 坚持下去 刷新/提交，无论是否 他们是在交易中完成的，或者 不。常见错误是，网络表单 进来并绑定一些无效数据 到实体上，验证失败，并且 尝试返回一个屏幕以通知 用户。建筑错误画面 涉及运行查询。询问 触发刷新/持久化提交 上下文。更改已绑定 实体刷新到数据库， 希望引起SQL异常，但是 也许只是持久保存损坏的数据。 （如果编程草率，则每个请求的会话当然也会发生问题4，但您不必强迫自己积极努力避免这种情况。）