Java JPA不考虑单笔交易中的更新

在事务服务方法中，我循环查询数据库，以获得实体a的前10个条件

我更新列表中的每个实体，使它们不再符合条件，并调用flush（）以确保进行更改

循环中对查询的第二个调用返回完全相同的一组实体

为什么不考虑实体上的刷新更改

我正在使用JPA2.0和Hibernate4.1.7。 与Hibernate相同的过程似乎只起作用。 我已经关闭了二级缓存和查询缓存，但没有任何效果

我使用的是一个相当简单的配置，JpaTransactionManager，Spring over JPA over Hibernate。用@Transactional注释的主方法

代码如下所示：

do {
    modelList = exportContributionDao.getContributionListToExport(10);
    for (M m : modelList) {
        //export m to a file
    m. (false);
    super.flush();
    }
} while (modelList.size() == 10);

在循环的每次迭代中，Dao方法总是返回相同的10个结果，JPA不考虑更新的“isToBeExported”属性

我不是想解决一个问题，而是想了解为什么JPA在这里的表现不如预期。 我认为这是一个“经典”问题。 毫无疑问，如果在每次迭代中都提交事务，那么问题就解决了

ASAIK，缓存L1，即Hibernate作为底层JPA提供者的会话，应该是最新的，第二次迭代查询应该考虑更新的实体，即使更改尚未持久化。

---

所以我的问题是：为什么不是这样？错误配置或已知行为？

Flush不一定提交数据库上的更改。你想要实现什么？据我所知，你做s.th。比如：

关于实体的循环

在循环中，更改实体

对实体调用“flush”

重新读取实体

您想知道为什么数据库中的数据没有更改

---

如果这是正确的，为什么要重新读取更改，而不使用元素？离开事务后，更改将自动持久化。

这肯定会起作用

这是我们的配置问题

抱歉，我们很难找出原因，但我希望答案至少对某些人有用：

---

JPA肯定会考虑单个交易中对实体所做的更改。

这里需要更多信息。包含代码循环、实体管理器的实例化、实体类的注释部分的SSCCE在哪里？此外，还应包括是否使用CMT，以及是否在查询中明确定义了锁定模式。额外的要点包括数据库模式的相关部分。是否在同一事务中查找A实体？这是关系的一部分吗？很抱歉没有提供SSCCE，我已经更新了原来的帖子。一切都发生在一个事务中。A不是关系的一部分，至少它没有在查询中使用。这是我们团队中的一位开发人员提交的原始代码。这不是一个好的设计，它已经被改变并解决了。为了理解JPA，我试图弄清楚这是否应该起作用，或者这是否是一种预期行为。