Java 使用标准API和JPQL找到的实体是否自动位于JPA的持久性上下文中？

我有一个关于JPA和实体经理的问题。如果我使用实体管理器的find方法，数据库中的数据将被加载，实体是实体管理器持久性上下文的一部分，可以被删除、修改或其他操作

但是，如果使用Hibernate的CriteriaAPI或JPA的JPQL或Hibernate的HQL从数据库中加载实体，会出现什么情况呢

通过使用Hibernate的Criteria API或JPA的JPQL或Hibernate的HQL创建的实体或实体是否自动成为实体管理器持久性上下文的完整部分，并且可以在我使用实体管理器的find方法时删除或修改

这个JPQL示例中的情况是什么：

JPQL：

从Kunde k选择k，kto.kontostand
左连接获取k.wohnort
左连接获取k.konten kto
k。geschlecht='m'和kto。kontostand<0

K和完整的实体kontostand是否完全是实体经理的一部分

非常感谢！

---

Maik

所有问题都没有单一答案，因为这些问题取决于：

• 使用哪种类型的实体管理器/持久性上下文（事务范围或i*扩展*）
• 给定的实体管理器操作是在事务内部调用还是在事务外部调用
• 给定的实体管理器操作或查询是否使用实体锁定

无论如何，我会引用JPA 2.0规范来回答您的问题：

3.1.1实体管理器接口

必须在中调用

persist

、

merge

、

remove

和

refresh

方法 当具有事务作用域的实体管理器 使用持久性上下文。如果没有事务上下文，则 抛出javax.persistence.TransactionRequiredException

find

方法（如果在没有锁的情况下调用或 使用

LockModeType.NONE

）和

getReference

方法 需要在事务上下文中调用。如果实体经理 事务范围的持久性上下文正在使用，结果 实体将被分离；如果实体管理器具有扩展的 如果使用持久性上下文，将对它们进行管理

注意：除了与Java EE相关的容器管理的持久性上下文（即：事务范围和扩展的）之外，还有应用程序管理的持久性上下文，它在范围上进行了扩展，可以在Java EE和SE环境中使用。确定你用的是哪一个

3.8.6查询执行

Query

和

TypedQuery

方法，而不是

executeUpdate

方法是 不需要在事务上下文中调用，除非有锁 除LockModeType之外的模式。未为查询指定任何模式。在里面 特别是，

getResultList

和

getSingleResult

方法不可用 需要在事务上下文中调用，除非有这样的锁 已为查询指定了模式。如果实体经理 事务范围的持久性上下文正在使用，结果 实体将被分离；如果实体管理器具有扩展的 如果使用持久性上下文，将对它们进行管理

假设您正在对查询使用并预取

kto

，则应将完整的

kontostand

分离（因此它不与任何持久性上下文关联）

---

我希望它能有所帮助。

CriteriaUpdate接口可用于实现批量更新操作。但是要小心，这些操作直接映射到数据库更新操作因此，持久性上下文与结果不同步，并且相关实体没有乐观锁定。如果使用乐观锁定，则需要在update语句中更新版本列

请参阅更多：

select k, kto.kontostand from Kunde k
left join fetch k.wohnort  
left join fetch k.konten kto
where k. geschlecht = 'm' and kto. kontostand < 0