The reason you see this working as it works is quite simple: JPA is defined to work that way.
I am assuming you trigger an update query for updateCamelName(…)
. The JPA specification states the following for update and delete operations:
The persistence context is not synchronized with the result of the bulk update or delete.
Caution should be used when executing bulk update or delete operations because they may result in inconsistencies between the database and the entities in the active persistence context. In general, bulk update and delete operations should only be performed within a transaction in a new persistence con- text or before fetching or accessing entities whose state might be affected by such operations.
This means, that if you need to see the changes of such an operation you need to do the following things:
- Clear the
EntityManager
after this operation. Spring Data JPA's @Modifying
annotation has a clearAutomatically
flag defaulting to false
. If that is set to true, invoking the query method will clear the EntityManager
automatically (as the name suggests. Use that with caution, as it will effectively drop all pending changes that have not been flushed to the database yet!
- Re-obtain a fresh instance of the entity from the
EntityManager
. Calling findOne(…)
on the repository seems like a reasonable way to do this as this roughly translates into EntityManager.find(…)
. Be aware that this might still hit 2nd level caches configured on the persistence provider.
The safest way to work around this is - as the spec suggests - to use update queries only for bulk operations and fall back to the "load entity, alter, merge" approach by default.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…