Does a JPQL bulk UPDATE touch an entity's version column, and what does the HQL keyword in 'update versioned Customer c set c.status = :s' actually do?

## The gap a bulk statement leaves Optimistic version columns work because every entity write includes the version in the WHERE clause and increments it in the SET clause; a write that matches zero rows means somebody else changed the row first. Bulk statements sit outside that protocol entirely. They neither check nor increment: 'update Customer c set c.status = ARCHIVED where c.lastLogin < :cutoff' becomes plain SQL touching only the status column. That produces a specific, nasty race. Session A loads customer 42 at version 7. A bulk statement archives customer 42; the row now has status ARCHIVED and version still 7. Session A edits a different field and flushes: update customer set name=?, status=?, version=8 where id=42 and version=7. One row matches, so no conflict is reported - and the UPDATE carries A's stale status, restoring the pre-bulk value. The bulk change is gone, quietly. ## What 'versioned' does HQL extends the update statement with a keyword placed before the entity name: 'update versioned Customer c set c.status = :status where c.lastLogin < :cutoff'. Hibernate then adds the version column to the generated SET clause, incrementing it. In the race above, customer 42 ends at version 8. Session A's flush issues its update with where id = 42 and version = 7, matches no rows, and Hibernate raises a stale-state failure - which is exactly what you want: the loser is told, rather than silently winning. Two things it is not. It is not a version check: the bulk statement's own WHERE clause is whatever you wrote, and no row is skipped because its version moved. And it is not portable - JPQL as specified has no versioned form, so this is HQL only. There is also no versioned bulk DELETE; deletion removes the row, so there is nothing left to invalidate. An alternative some people reach for is putting the version in the SET clause by hand, set c.version = c.version + 1. The JPA specification says the update statement should not touch the version attribute directly; Hibernate generally permits it, but the versioned keyword expresses the intent clearly and handles the version type properly, so prefer it. ## Practical guidance Use the versioned form whenever a bulk statement modifies rows that long-running or interactive sessions may be holding - editable master data, workflow status, anything a user has open in a screen. The cost is one extra column in the SET clause and the guarantee that concurrent editors get an honest failure instead of a lost update. Skip it when the affected rows are not held elsewhere - purely batch-owned tables, ingestion staging, denormalised counters - since bumping versions there only creates spurious conflicts for other batch jobs. And remember what remains true regardless: the bulk statement still bypasses the persistence context, so entities already loaded in the current session are stale, including their version snapshot. If you bump versions and then flush a stale instance loaded in the same session, you will hit the stale-state failure yourself. Clear the persistence context after the statement, as with any bulk operation. ## Relationship to the object-layer alternative If conflict detection matters row by row - you want to skip rows that changed rather than invalidate their holders - a bulk statement is the wrong tool: load the entities, mutate them, and let normal versioned writes decide, or express the condition in the bulk statement's WHERE clause explicitly (for example and c.version = :expected) so only untouched rows are affected. The second option is set-based and cheap, but it silently skips rows rather than reporting them, so pair it with the returned row count.