简体   繁体   English

JPA未在单笔交易中考虑更新

[英]JPA not taking update into account within single Transaction

Within a transactional service method, I loop on querying a database to get the first 10 of entity A with a criteria. 在事务服务方法中,我循环查询数据库以获取具有条件的实体A的前10个。

I update each A entity from the list so that they don't match the criteria anymore, and call a flush() to make sure changes are made. 我从列表中更新了每个A实体,以使它们不再符合条件,并调用flush()以确保进行了更改。

The second call to the query within the loop returns the exact same set of A entities. 在循环中第二次调用查询将返回完全相同的A实体集。

Why isn't the flushed change on the entities taken into account? 为什么不考虑对实体进行的冲洗更改?

I'm using JPA 2.0 with Hibernate 4.1.7. 我在Hibernate 4.1.7中使用JPA 2.0。 The same process with Hibernate only seems to be working. 与Hibernate相同的过程似乎仅在起作用。 I've turned off the second level cache and the query cache, to no avail. 我已经关闭了二级缓存和查询缓存,但无济于事。

I'm using a rather plain configuration, JpaTransactionManager, Spring over JPA over Hibernate. 我使用的是JpaTransactionManager,它是Hibernate上的JPA上的Spring。 Main method annotated with @Transactional. 用@Transactional注释的主要方法。

The code would be something like this: 该代码将是这样的:

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

With each iteration of the loop, the Dao method always return the same 10 results, JPA not taking into account the updated 'isToBeExported' attribute. 在循环的每次迭代中,Dao方法始终返回相同的10个结果,而JPA并未考虑更新的“ isToBeExported”属性。

I'm not trying to solve a problem, rather I want to understand why JPA is not behaving as expected here. 我不是要解决问题,而是要了解为什么JPA的行为不符合此处的预期。 I expect this to be a 'classic' problem. 我希望这是一个“经典”问题。 No doubt it would be solved if the Transaction would be commited at each iteration. 毫无疑问,如果在每次迭代中都提交事务,将可以解决。

ASAIK, the cache L1, ie the Session with Hibernate as the underlying JPA provider, should be up to date, and the second iteration query should take into account the updated Entities, even though the changes haven't been persisted yet. ASAIK,缓存L1(即,将Hibernate作为基础JPA提供程序的会话)应该是最新的,并且第二次迭代查询应考虑更新的Entities,即使尚未持久保留更改。 So my question is: why isn't it the case? 所以我的问题是:为什么不这样呢? Misconfiguration or know behavior? 配置错误或知道行为?

Flush does not necessarily commit the changes on the database. 刷新不一定会在数据库上提交更改。 What do you want to achieve? 您想实现什么? From what I understand you do s.th. 据我了解,你做某事。 like: 喜欢:

  1. Loop about entities 关于实体的循环
  2. Within the loop, change the entity 在循环中,更改实体
  3. Call 'flush' on the entity 在实体上调用“冲洗”
  4. Read the entity back again 再次读回实体
  5. You wonder why the data did not change on the database? 您想知道为什么数据库中的数据没有更改?

If this is correct, why do you re-read the changes and just don't work with the elements? 如果这是正确的,为什么您要重新阅读所做的更改而又不使用元素? After leaving the transaction, the changes will be automagically made persistent. 离开事务后,更改将自动保持不变。

This should definitely be working. 这肯定应该起作用。

This is a configuration problem on our part. 这是我们的配置问题。

Apologies for the question, it was pretty hard to spot the reason on our part, but I hope the answer will at least be useful to some: 对于这个问题,我们深表歉意,很难找出原因,但我希望答案至少对某些人有用:

JPA definitely takes into account changes made on entities within a single transaction. JPA绝对会考虑在单个事务中对实体所做的更改。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM