hibernate - Bypass managed entities or not on JPA -

why jpa entitymanager execute mutable query e.g. update against db directly, choose execute select query first against persistence context (aka second-level cache) below (tested hibernate 5)?

it doesn't seem jpa spec has prescribed so. gain better performance @ risk of inconsistency?

/* ... */  string name = em.find(person.class, 1).getname();  em.gettransaction().begin(); em.createquery("update person set name='new' id=1")   .executeupdate();  em.gettransaction().commit(); // db updated entity not  person p = em   .createquery("select p person p id=1", person.class)   .getsingleresult(); // stale entity returned  assertequal(name, p.getname()); // true 

probably performance reasons, if jpql query matches entity loaded in entity manager in memory, specification does not require refresh entity in memory current state in db.

in example, happens in background - person entitiy id 1 retrieved db (it exists in entitymanager cache) - person's name updated in db via jpql (the entity remains unchanged) - entity person id 1 retrieved db -- entity id 1 exists in entitymanager, therefore instance returned (it has old value in name) - entity not merged db. more info see answer this question.

this behavior in compliance jpa requirement in single entitymanager, there cannot 2 instances of entity single row in db. there 2 options how solve it, 1 merge existing entity state in db, ignore data in db. jpa spec chose second option.

if would not retrieve person id 1 in beginning, retrieve new entity in select query new values.

a solution have fresh data in entity use em.clean() between update , select queries, mind clear entities cache, not person(id=1) entity, , have other sideeffects.

however, safer solution use em.refresh() after changed entities update script.