应用程序管理的 JPA，何时需要事务

Posted 2023-04-14

【中文标题】应用程序管理的 JPA，何时需要事务

【英文标题】：Application managed JPA, when is Transaction needed

【发布时间】：2014-02-10 08:45:31

【问题描述】：

我们正在开发一个使用 JPA (Eclipselink) 完成数据层的小型 Web（将在 Tomcat 上运行）。 我前段时间做过类似的事情。但我总是不确定何时需要开始和结束事务或进行刷新。 目前，如果我添加（持久）和删除对象，我会使用事务。如果我在已经持久化的对象上调用 setter，我不会使用事务。

是否有指南/教程或简短回答何时使用事务或如何正确实施应用程序管理的 JPA。

【参考方案1】：

我认为可以总结出您问题的答案。 几乎所有 JPA 操作都需要事务，除了不锁定实体的查找/选择（即任何不更改数据的 JPA 操作）。

（JTA 事务范围的实体管理器） 对于 JTA 事务范围的实体管理器，最好引用规范（第 3 章实体操作）：

persist、merge、remove 和 refresh 方法必须在内部调用 当实体管理器具有事务上下文时 使用事务范围的持久性上下文。 如果没有事务上下文，则抛出 javax.persistence.TransactionRequiredException。

必须调用指定 LockModeType.NONE 以外的锁定模式的方法 在事务上下文中。 如果没有事务上下文，则抛出 javax.persistence.TransactionRequiredException。

find 方法（前提是它在没有锁的情况下调用或使用 LockModeType.NONE) 和 getReference 方法不需要 在事务上下文中调用。如果实体经理与 事务范围的持久性上下文正在使用中，结果 实体将被分离；如果实体管理器具有扩展 使用持久性上下文，它们将被管理。请参阅第 3.3 节了解 实体管理器在事务外使用。

（应用程序管理/资源本地实体管理器） 对于应用程序管理的实体管理器，JPA 规范并不清楚该行为。在 Hibernate 的情况下，当不在事务中时发生的事情非常复杂（它还可能取决于 JDBC 驱动程序和数据库连接的自动提交模式）。在这个主题上查看Hibernate's article。 强烈建议您始终使用事务进行上述操作。

对于您问题的第二部分：如果您调用了托管实体的设置器，并且没有刷新您将其分离（即在事务提交之前），则行为不清楚/未定义，即您应该更好地更正代码。

错误代码示例：

//begin Transaction
MyEntity entity = em.find(MyEntity.class, 1L);
entity.setField("New value");
em.detach();//it is not sure whether the "New value" will be persisted. To make sure it is persisted, ypu need to call em.flush() before detaching
//commit Transaction

通常如果 DB 操作的顺序（与实体管理器操作的顺序不同）并不重要，您可以让 JPA 实现决定何时刷新（例如在事务提交时） .

【讨论】：

所以对于设置者我需要刷新但我不需要开始/结束事务？但是为什么要冲洗呢？正如我在这里和那里阅读的那样，flush 似乎清空了 sql 命令缓存（立即执行所有操作），但为什么不让 JPA-Implementation 决定何时执行呢？

所以如果没有调用 em.detach() 代码就可以了吗？没有错误代码：MyEntity entity = em.find(MyEntity.class, 1L); entity.setField("新值");

是的，当然。这是“通常情况”。 flush 将在事务提交时自动调用 :)

根据我的经验：虽然 JPA 规范需要一个事务，并说如果没有事务绑定到会话（对于那些提到的操作）应该抛出 TransactionRequiredException，但对于资源本地实体来说manager 没有抛出异常（例如它是 JAVA EE 上下文中的 Hibernate）。无论如何，你能发布一些你的代码吗？此外，当您更改数据时，确实建议在所有这些情况下使用事务。还可以尝试禁用持久性提供程序（在您的情况下为 ElipseLink）的自动提交模式以强制执行事务。

还可以查看这篇文章，了解未设置显式事务边界时的行为：community.jboss.org/wiki/…（ElipseLink 的行为应该类似）