将 Hibernate 4.1 和 JPA 2.0 与实体管理器一起使用，将具有子实体的多个实体加载到多个级别的最佳方法是什么？

Question

我们正在使用带有实体管理器实现的 Hibernate 4.1.4，并且对它非常满意。当加载单个实体或一小组实体（10-50 + 子实体）时，我们获得了出色的性能，并且我们所有的连接都工作得很好并且是双向的。编辑/保存/删除轻而易举！

加载 2500 个实体和相关数据以进行报告

当我们尝试加载数百或数千个实体以及子实体时，我们遇到了问题。在一个示例中，我们有大约 2500 个基本实体以及两个一对一连接和三个一对多连接。这导致 2500 x 5 +1 查询。使用我们的数据库 (DB2) 执行大约需要 30 秒。

我们使用动态查询和实体管理器创建查询方法：

http://docs.jboss.org/hibernate/orm/4.1/javadocs/

http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html

尝试哄骗 Hibernate 使用联接

我们的观察结果是，无论我们尝试什么，我们似乎都无法让休眠状态来执行大量子实体作为主查询的连接。当使用 find 方法和主键加载单个实体时，hibernate 使用连接，但当加载多个基本实体时，它不会。

我们已经尝试了条件 api，结果相同。

在查询中检索多个实体的一些成功

例子：

select a,b from table1 a left join table2 b

我们已经部分成功地在查询中手动连接并通过元组检索单个实体，但这绕过了我们的带注释的实体模型并且不是首选方法（如果我们可以避免的话）。

http://docs.jboss.org/hibernate/orm/4.1/manual/en-US/html_single/#objectstate-querying-executing

我们遇到的元组问题是它们与主要实体分离（这似乎合乎逻辑，因为它们不是通过注释关系加载的）并且似乎没有办法重新附加它们。在手动添加实体列表中的所有一对多记录后，当 hibernate 命中列表的 get 方法时，它仍然尝试急切/延迟加载列表（尽管列表已经设置）。

尝试的优化 - 数据集的预加载

我们尝试的另一种优化技术是提前预加载数据集。在加载所有核心实体后，我们构建了一个 pk 列表并触发了一个查询以加载所有一对多数据集。但是当hibernate再次点击列表数据的getter时，它再次尝试急切/延迟加载列表，忽略会话中已经预加载的内容（可能需要启用缓存？）。

建议？

我们正朝着许多不同的方向前进，但收效甚微，希望有人能够为我们指明正确的道路（或指出新的道路！）！

Answer 1

看来我自己也想通了！两种策略解决了这个问题：

1. 查询中的联接获取处理一对多联接！当然你只能做一个 join fetch 因为 Hibernate 会抛出 cannot 同时 fetch multiple bag 异常。

   例子：

   LEFT OUTER JOIN FETCH t.table3 t3
   

2. 对于其他联接，@Fetch(FetchMode.SUBSELECT) 成功了！

有效地将查询总数从数千个减少到几个。在一个示例中，选择了 188 个核心实体，总共执行了 12 个查询。额外的查询大多是一对一的查找，对总执行时间没有显着影响（平均 1-2 秒）。无论选择 188 条还是 1888 条记录，查询的总数都没有明显增加。

如果有人想了解更多信息，请随时与我联系或发表评论！ :)