应用程序管理JPA，何时需要Transaction [英] Application managed JPA, when is Transaction needed

问题描述

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

We are working on a little web (will run on Tomcat) with the data layer done with JPA (Eclipselink). I did similar thing some time ago. But i were always unsure when i need to begin and end transactions or do a flush. At the moment i use transaction if i add (persist) and remove objects. If i call setters on an already persisted object i do not use transactions.

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

Is there a guide/ tutorial or a short answer when to use transactions or how to implement application managed JPA correctly.

推荐答案

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

I think one can summarize an answer to your question. almost any JPA operation needs a transaction, except find/selects that do not lock entities (i.e any JPA operation that does not change the data).

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

(JTA transaction-scoped entity manager) In the case of an JTA transaction-scoped entity manager it is better to quote from the spec (Chapter 3 Entity Operations):

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

The persist, merge, remove, and refresh methods must be invoked within a transaction context when an entity manager with a transaction-scoped persistence context is used. If there is no transaction context, the javax.persistence.TransactionRequiredException is thrown.

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

Methods that specify a lock mode other than LockModeType.NONE must be invoked within a transaction context. If there is no transaction context, the javax.persistence.TransactionRequiredException is thrown.

find方法（假设它没有锁定调用或用
LockModeType.NONE调用）并且getReference方法不需要是
在事务上下文中调用。如果正在使用具有
事务范围持久性上下文的实体管理器，则将分离生成的
实体;如果使用具有扩展
持久性上下文的实体管理器，则将对它们进行管理。有关
实体经理在交易外使用，请参阅第3.3节。

The find method (provided it is invoked without a lock or invoked with LockModeType.NONE) and the getReference method are not required to be invoked within a transaction context. If an entity manager with transaction-scoped persistence context is in use, the resulting entities will be detached; if an entity manager with an extended persistence context is used, they will be managed. See section 3.3 for entity manager use outside a transaction.

（应用程序管理/资源本地实体经理）
对于应用程序管理的实体管理器，JPA规范并不清楚该行为。在Hibernate的情况下，当不在事务内部时（它也可能依赖于JDBC驱动程序和DB连接的自动提交模式），发生的事情非常复杂。查看有关此主题的 Hibernate的文章。 基本上，我们强烈建议您始终使用交易进行上述操作。

到问题的第二部分：如果你打电话给二传手一个托管实体，没有刷新你分离它（即在事务提交之前），行为不清楚/未定义，即你应该更好地纠正代码。

To the second part of your question: if you called a setter of a managed entity, and without flushing you detached it (i.e before transaction commit), the behavior is unclear/undefined, i.e you should better correct the code.

示例有缺陷的代码：

//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操作的顺序（与enity manager操作的顺序不一样）不重要，您可以让JPA实现决定何时刷新（例如，在事务上）承诺）。

Usually if the order of DB operations (not the same as the order of enity manager operations) is not important, you can leave the JPA implementation to decide when to flush (e.g on transaction commit).

这篇关于应用程序管理JPA，何时需要Transaction的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！