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 EntityManagerafter this operation. Spring Data JPA's@Modifyingannotation has aclearAutomaticallyflag defaulting tofalse. If that is set to true, invoking the query method will clear theEntityManagerautomatically (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. CallingfindOne(…)on the repository seems like a reasonable way to do this as this roughly translates intoEntityManager.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.