本机查询和 jpa答案

【问题标题】：native query and jpa本机查询和 jpa
【发布时间】：2016-11-02 17:16:02
【问题描述】：

使用 jpa 原生查询时
事务传播是我们正在使用的正确 JPA 的唯一功能吗？

在我看来，我就像使用普通的旧 jdbc pluc jpa 事务传播

所以没有持久化上下文的概念？

你能验证我的想法，并指出我的一些官方文档吗？

编辑：

使用返回实体的 SQL 查询需要注意的一点是生成的实体实例由持久性管理上下文，就像 JP QL 查询的结果一样。

我正在阅读 PRO JPA 这本书，并且根据我的理解
当我们使用 jpa 本机查询来获取一组标量值时（与我们使用 jdbc 的方式非常相似），实际上并没有托管实体和持久性上下文的概念。当我们通过本机查询检索实体时，事情当然会发生变化。

【问题讨论】：

不确定您的确切意思。 JPA 规范将是您应该参考的内容，但是通过 EntityManager 上下文执行本机查询会为您提供与 JPQL 查询相同的东西 - 您可以访问原始数据或让 JPA 构建您的托管实体。如果您打算使用它来管理 JDBC 连接和执行 SQL 的语句，那么您将错过 JPA 的主要优势。
那么在 jpa 中使用原生查询，我们不是完全绕过了持久化上下文吗？
据我了解，我们确实...您能帮我理清这些想法吗？
正如书中所述，本机查询不会绕过上下文。如果你读入原始数据，这就是你得到的。但是，如果您有一个本机查询并告诉 JPA 从中构建一个实体 (em.createNativeQuery(sqlstring, entity.class))，它将返回托管实体 - 它跟踪任何更改并将这些更改与数据库。就像 JPQL 查询一样。您的问题非常广泛 - 为什么不专注于您具体要寻找和要做的事情？

【解决方案1】：

根据我的经验，执行 JPA 本机查询和 JDBC 查询所需的时间有很大差异。可能是由于创建了持久化上下文。

【讨论】：

这些成本应该是预先产生的，就像在创建连接的数据源时一样，如果您有效地管理生命周期，这些成本应该是一次性成本。
如何“预先”创建持久性上下文？
您可以在部署期间创建它，然后保留它。您无需在需要执行查询的任何时候创建持久性单元。否则，如果您只是执行返回原始数据的本机查询，大多数提供程序应该为您提供与通过 JDBC 执行类似的性能。
抱歉，为每个事务创建一个持久性上下文。你的意思是我应该对所有查询使用一个事务？
上下文本身应该是轻量级的，而 EntityManagerFactory 拥有大部分 JPA 处理。如果您在 JPA 与 JDBC 中看到原生查询的巨大开销，那么还有其他问题 - 例如维护大型缓存或让 JPA 构建低效的对象模型而不是从 JDBC 获得的原始数据。甚至在查询中考虑上下文部署成本。