You run a bulk JPQL statement such as "update Product p set p.price = p.price * 1.1 where p.category = :c" via Query.executeUpdate(). What happens to Hibernate's second-level cache and to entities already loaded in the current persistence context?

## What bulk DML is A bulk statement is a JPQL/HQL `update` or `delete` executed with `Query.executeUpdate()`. It is not a loop over entities: Hibernate translates it into a single SQL statement and sends it to the database. That is why it is fast, and also why it sidesteps almost everything the ORM normally does for you: no entity instances, no dirty checking, no cascade, no `@PreUpdate` callbacks, no optimistic version bump unless you write one into the statement yourself. ## Effect on the second-level cache Hibernate tracks, for every query, the set of tables it touches, known as query spaces. For bulk DML it knows the query spaces but not the primary keys of the affected rows, since the database applied the `where` clause and never reported which rows matched. With no key list, precise invalidation is impossible, so Hibernate takes the conservative route: - the entity cache regions mapped to those tables are evicted wholesale; - collection regions belonging to those entities are evicted; - the update-timestamps cache is stamped for those spaces, which makes every cached query result over them stale. This is correct but blunt. One `update Product ...` touching ten rows throws away every cached `Product`, and on a busy node the immediate consequence is a burst of database reads while the region refills. On a warm system a bulk statement over a heavily cached table is a small self-inflicted stampede, which is why such jobs are usually scheduled off-peak or split into narrower entities. ## Effect on the persistence context The first-level cache is untouched. If the session already holds `Product#7` with `price = 10`, that instance still says 10 after the bulk statement raised it to 11. Worse, its loaded snapshot also says 10, so: - a later `em.find(Product.class, 7L)` returns the stale managed instance without going to the database; - if you then change some unrelated field, the generated UPDATE writes the whole row from the stale in-memory state and can silently undo the bulk change. Hibernate flushes pending changes before executing the bulk statement (so your own dirty entities are not lost), but it does not and cannot re-read what the statement did. ## The safe pattern ``` em.createQuery("update Product p set p.price = p.price * 1.1 where p.category = :c") .setParameter("c", cat) .executeUpdate(); em.clear(); // drop stale managed copies ``` Either run bulk DML in a short session dedicated to it, or `clear()` afterwards, or `refresh()` the handful of entities you still need. In a versioned entity, remember to bump the version column inside the statement (`set p.version = p.version + 1`) so that concurrent optimistic checks still behave. ## Native SQL is worse A native `update`/`delete` executed through Hibernate carries no query-space information unless you supply it. Without `addSynchronizedEntityClass(...)` (or the equivalent on a named native query), Hibernate evicts nothing and the second-level cache keeps serving pre-update rows indefinitely. ## What interviewers are checking They want to hear that bulk DML bypasses the ORM layer, that cache invalidation happens at region granularity because identifiers are unknown, that the persistence context is a separate problem you must solve by hand, and that native SQL needs explicit table declarations. Candidates who answer only "Hibernate handles it" have not thought about the two caches separately.