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

Question

使用JPA实现跨多个http请求的业务事务似乎有两种模式：

1. 具有分离实体的每个请求的实体管理器
2. 扩展持久化上下文

这些模式的各自优势是什么？何时应该优先考虑？

到目前为止，我提出了：

• 扩展持久化上下文保证对象标识等同于数据库标识，简化编程模型并可能消除实现实体等于的需要
• 分离实体比扩展持久化上下文需要更少的内存，因为持久化上下文还必须存储实体的先前状态以进行更改检测
• 不再引用分离的实体有资格进行垃圾回收;必须首先明确地分离持久对象

然而，由于没有任何JPA的实践经验，我确信我已经错过了一些重要的事情，因此这个问题。

如果重要：我们打算使用由Hibernate 3.6支持的JPA 2.0。

编辑：我们的视图技术是JSF 2.0，位于EJB 3.1容器中，带有CDI，可能还有Seam 3.

Answer 1

好吧，我可以通过尝试在Web环境中使用扩展持久性上下文来列举挑战。有些事情还取决于您的视图技术是什么，以及它是绑定实体还是视图级中间人。

1. EntityManagers不是线程安全的。 每个用户会话不需要一个。 每个用户会话需要一个 浏览器标签。
2. 当出现异常时 EntityManager，它被认为 无效，需要关闭 更换。如果你打算 编写自己的框架扩展 用于管理延长的生命周期， 这需要实现 是防弹。一般来说 EM-per-request设置异常 去某种错误页面和 然后加载下一页创建一个 无论如何总是喜欢新的 有。
3. 对象平等不会 100％自动安全。如上， 异常可能已失效 上下文中加载的对象 与之相关，所以一个人拿来了 现在不会平等。做到这一点 假设也是假设极端 高水平的技能和 了解JPA的工作原理和方法 EM之间的作用是什么 开发人员使用它。例如。， 不小心使用合并时 不需要将返回一个新的 不满足==的对象 与其场相同 前任。 （像对待一样对待合并 SQL'更新'是一个非常常见的 特别是JPA noobie'错误' 因为它只是一个无操作的大部分 所以它滑过的时间。）
4. 如果您正在使用视图技术 绑定POJO（例如，SpringMVC） 并且您计划绑定Web表单 数据直接进入您的实体， 你会很快陷入困境。 对附加实体的更改将 在下一个变得坚持不懈 flush / commit，无论是否 他们是在交易中完成的 不。常见错误是，网络表单 进来并绑定一些无效数据 在实体上，验证失败并且 尝试返回屏幕通知 用户。构建错误屏幕 涉及运行查询。询问 触发刷新/提交持久性 上下文。变更必然附加 实体刷新到数据库， 希望造成SQL异常，但是 也许只是坚持腐败的数据。

（问题4当然也可以在每个请求的会话中发生，如果编程很草率，但是你没有被迫积极努力避免它。）