You must protect a legacy table against lost updates and can either add a dedicated version column or use Hibernate's column-comparison optimistic locking on the existing columns. How do you decide, and what does column comparison fail to protect?

## Frame the decision, not the annotation Both strategies detect the same thing — that the row moved between your read and your write — and both signal it the same way: the `UPDATE` affects zero rows, and Hibernate converts that into a stale-state failure. The difference is *what carries the evidence*, and that drives everything else. ## Why the dedicated column usually wins A version column is one small integer or timestamp, compared and incremented on every write. Its properties are hard to beat: - **It survives detachment.** The value lives in the entity, so it can go out to a browser in a form, come back hours later, and still be checked. Column comparison cannot do this, and for request-per-edit web applications that is often the *only* concurrency window that matters. - **Cheap and index-friendly predicates.** `where id = ? and version = ?` is two equality tests on a narrow tuple. Full-row comparison drags every column into the predicate, including nullable ones that need `(col = ? or (col is null and ? is null))`. - **Portable.** Version-based locking is standard JPA; `@OptimisticLocking` is Hibernate-specific. - **A first-class value.** You can expose it as an HTTP ETag, log it, or deliberately bump it to invalidate other readers. So the real question is not "which is better" but "can I add the column". Adding one to a legacy table is usually a nullable-column migration plus a backfill, and Hibernate's own writes maintain it thereafter. ## When you genuinely cannot Two situations force the fallback. First, **shared ownership**: stored procedures, ETL jobs or other applications write the table and will never increment your column, so rows would be modified without the version moving — a version column that is not maintained is worse than none, because it looks like protection. Second, **no DDL authority**: a vendor schema, a replicated table, or an organisational boundary. Column comparison is designed exactly for this. It writes nothing extra, requires no cooperation, and can be switched on per entity. ## The gaps, in order of how often they bite **Detached windows.** The comparison values come from the loaded-state snapshot Hibernate keeps for dirty checking. That snapshot exists only while the entity stays managed in the persistence context that loaded it. `merge` on a detached instance re-reads the row, so the snapshot becomes the *current* state, and any concurrent change during the detached window disappears without a trace. If your architecture edits detached objects, this strategy does not cover your actual risk — you would need to carry the old values yourself and compare them explicitly, which is reimplementing a version column badly. **Columns that do not compare well.** Large text and binary columns are expensive or outright illegal in a `WHERE` clause on several engines; floating point values may not round-trip identically through the driver; timestamps can lose sub-second precision. `@OptimisticLock(excluded = true)` removes such a column from the check, at the price of a deliberate blind spot — concurrent changes to it become invisible. **Predicate cost.** Wide `WHERE` clauses with null-safe branches are bigger statements and can make the optimiser's job harder. Usually the primary-key lookup still dominates, but on very wide rows measure rather than assume. **No externally visible version.** Nothing to hand a client as a concurrency token, and no equivalent of deliberately bumping a parent to signal that an aggregate changed. **Under DIRTY, cross-column invariants.** Comparing only modified columns lets two transactions edit disjoint fields and both commit, which breaks any rule that relates fields to each other. ## How I would decide If the table is mine: add the version column, full stop. If it is shared but I control all *application* writes and the external writers only read: still add the column. If external writers modify rows: use `ALL` column comparison, exclude only columns that cannot be compared, keep read-modify-write inside a single persistence context so the snapshot is meaningful, and be explicit in the design notes that detached edits are unprotected. If contention on independent fields turns out to be a real problem, consider `DIRTY` — but first ask whether the entity is doing too many jobs and should be split into narrower entities with their own lifecycles. And where correctness truly cannot tolerate a retry loop, neither strategy is the answer: take a pessimistic lock so the conflict cannot arise at all.