You run the JPQL statement UPDATE Product p SET p.price = p.price * 1.1 through Query.executeUpdate(). What happens to entities already loaded in the current persistence context, and what happens to Hibernate's second-level cache?

## What executeUpdate actually does JPQL has UPDATE and DELETE statement forms, and HQL adds INSERT ... SELECT. They are executed with Query#executeUpdate(), which returns the row count. Hibernate parses the statement, maps entity and attribute names to tables and columns, and emits SQL that the database applies set-at-a-time. Nothing is read into memory. That is the whole point: updating a million rows costs one statement instead of a million SELECTs, a million dirty checks and a million UPDATEs. The cost of skipping the object layer is that everything the object layer normally does is skipped too: - No entity instances are created, so no lifecycle callbacks or entity listeners run: @PreUpdate, @PostUpdate, @PreRemove are not invoked. - No cascading and no orphan removal. - No dirty checking, no snapshot maintenance. - Attribute converters and derived-value mappings are not applied to your SET expression the way they are for entity writes, so what you write is close to raw SQL semantics. ## The first-level cache is not updated The persistence context is a map of identifier to managed instance plus a snapshot of each instance's loaded state. A bulk statement changes rows in the database without telling that map anything. So a Product loaded at price 100 still reports 100 after the statement raised it to 110, and calling find() again returns the same cached instance rather than re-reading. Two failure modes follow. First, plain staleness - code that reads the entity afterwards sees the old value. Second, and worse, write-back: if you now set another field on that instance and the transaction flushes, dirty checking compares the instance against the stale snapshot and emits an UPDATE containing the old price, silently undoing the bulk change. The mitigations are ordering and explicit invalidation. Run bulk statements before loading the entities they touch; or after executing call em.clear() to detach everything, or em.refresh(p) for the specific instances you must keep. Note clear() also discards unflushed changes, so flush first if you have any - although Hibernate's auto-flush before the bulk statement usually took care of that. ## The second-level cache is handled, with a caveat A common but wrong belief is that bulk statements leave the shared second-level cache stale forever. For HQL/JPQL bulk statements Hibernate schedules a cleanup that invalidates the cache regions belonging to the statement's query spaces - the entity regions for affected tables, related collection regions, and query cache regions. It is a coarse invalidation, not a targeted update: the whole region for the entity is dropped, so the next reads go to the database. The caveat is native SQL. Hibernate cannot parse arbitrary SQL to learn which tables it touches, so a native mutation must declare its affected entities or tables (its query spaces). Otherwise the second-level cache genuinely does go stale. ## Auto-flush before, nothing after Bulk statements are queries as far as flush mode is concerned. Under the default AUTO flush mode Hibernate flushes pending changes whose tables overlap the statement's query spaces before executing it, so your in-memory work is applied first and the bulk statement sees it. There is no symmetric step afterwards - Hibernate never re-reads to reconcile the persistence context. ## Multi-table entities If the entity spans several tables - joined inheritance, or a secondary table - a single SQL statement cannot express the operation. Hibernate then uses an id-table strategy: it selects the matching identifiers into a temporary table and issues one statement per underlying table against it. Which flavour (global temporary table, local temporary table, an inline list of ids) is chosen depends on the dialect and can be configured, and it explains the unexpected CREATE/INSERT statements people see in the log for a one-line bulk delete. ## When to reach for it Use a bulk statement when the change is expressible in SQL and applies to many rows: flag flips, price adjustments, archiving, purging. Use entity mutation when you need callbacks, cascades, validation or per-row business logic. Mixing both in one transaction is where bugs live - so keep bulk work at the start, or in its own transaction.