Hibernate's @OptimisticLocking annotation accepts OptimisticLockType.ALL and OptimisticLockType.DIRTY. How do the generated UPDATE statements differ, and what concurrency anomaly does DIRTY still allow?

## Two ways to build the WHERE clause Both types replace a version check with a comparison against values read earlier; they differ in how many columns they compare. **ALL** — every mapped column of the entity goes in: ```sql update product set price = ? where id = ? and name = ? and price = ? and stock = ? ``` The row is treated as a single unit of consistency. Any concurrent change to any column, even one you do not care about, makes your update affect zero rows and Hibernate raises a stale-state exception. **DIRTY** — only the columns this flush modifies: ```sql update product set price = ? where id = ? and price = ? ``` The unit of consistency shrinks to the individual column. Someone else may change `stock` concurrently and both updates succeed. ## What you gain from DIRTY Fewer false conflicts. On a wide row edited by several independent processes — a pricing job, an inventory feed, a support tool changing a description — `ALL` makes every one of them a potential conflict for every other, and users see failures for edits that never actually overlapped. `DIRTY` lets those writers coexist. The statements are also smaller, which matters when the row has many columns. ## What DIRTY costs It silently gives up any invariant that spans more than one column. Concretely: a rule says `discount` may never exceed 50% of `price`. Transaction A reads (price 100, discount 40) and lowers the price to 60 — legal against what it read. Transaction B reads the same row and raises the discount to 45 — also legal against what it read. Under `DIRTY`, A's `WHERE` mentions only `price` and B's only `discount`, so neither collides, both commit, and the row settles at (60, 45), which violates the rule. Nothing failed, nothing was logged; the data is simply wrong. Under `ALL`, the second update matches zero rows and one transaction is told to retry. The same trap appears with state machines: a `status` column and the fields that justify a status are usually a single logical value, and letting them move independently produces rows in states your code believes are unreachable. There is a second, subtler effect. `DIRTY` compares only the columns you changed, so it also cannot detect that the row was concurrently changed in a way that *invalidates your decision to write at all* — for instance a row transitioning to `CANCELLED` while you update its shipping address. If a read influenced your write, `ALL` is the type that reflects that dependency. ## Mechanics you should mention `DIRTY` needs `@DynamicUpdate`: the set of compared columns varies per flush, so Hibernate cannot use its pre-generated static statement. `ALL` is conventionally paired with it too, so the `SET` clause stays limited to changed columns. Both types share the limitations of versionless locking generally: the comparison values come from the persistence context's loaded-state snapshot, so protection ends at detachment; nullable columns require null-safe comparisons that bloat the SQL; and columns that compare poorly (large text or binary, some floating point) may need `@OptimisticLock(excluded = true)`, which creates a deliberate blind spot. Note that excluding columns under `ALL` gives you something close to a curated middle ground between the two types. ## How to choose Default to `ALL`: it matches the mental model "the row is the unit of consistency", which is what a version column also gives you, and it fails loudly rather than corrupting quietly. Move to `DIRTY` only when you have identified a real contention problem *and* can state that the columns involved carry no cross-column rules. And if a row's fields are genuinely independent enough that `DIRTY` looks attractive, that is often a hint the entity should be split into separate entities with their own lifecycles.