A user opens an edit form on a record, spends several minutes changing it, and submits. How do you use a JPA @Version field to detect that somebody else changed that row in the meantime, and what common implementation mistake silently defeats the check?

## Why the normal mechanism is not enough Optimistic locking inside a single transaction protects you between load and flush — microseconds to seconds. A user editing a form is a **conversation**: minutes elapse, and there is no open persistence context, no transaction, and no snapshot on the server. Nothing in the ORM spans that gap by itself. What spans it is the version *value*, if you carry it. ## The pattern **Request 1 — render.** Load the record and include the version in whatever leaves the server: ```java record ProductForm(Long id, String name, BigDecimal price, long version) {} ``` Or as an HTTP `ETag`, which the client returns in `If-Match` — the same idea expressed at the protocol level. **Request 2 — submit.** Build a **detached** entity from the submitted data *including the version*, and merge it: ```java Product p = new Product(); p.setId(form.id()); p.setVersion(form.version()); // the version the user actually saw p.setName(form.name()); p.setPrice(form.price()); em.merge(p); ``` Hibernate's `merge` loads the current row into the persistence context and compares the detached instance's version with it. If the detached version is older, it raises `OptimisticLockException` right there — you do not even wait for the flush. If they match, the state is copied onto the managed entity and the flush emits the usual versioned update, which catches any change that occurred in the milliseconds since the merge read. ## The mistake that silently defeats it By far the most common implementation: ```java Product managed = em.find(Product.class, form.id()); // fresh row, current version managed.setName(form.name()); managed.setPrice(form.price()); // version never compared to what the user saw ``` This compiles, passes tests, and is completely unprotected. The managed instance was loaded *now*, so its version is whatever the other user's edit left behind. The flush emits `where version = <current>`, matches one row, and the other user's change is gone. No exception, no log line — the exact lost update the mechanism exists to prevent. The rule: **the version must come from the client's copy of the data**, not from a fresh read. A safe variant of the load-then-copy style is to load the entity and compare explicitly before mutating — `if (managed.getVersion() != form.version()) throw conflict;` — or to call `em.lock(managed, LockModeType.OPTIMISTIC)` after checking, but the merge-a-detached-instance form is less error-prone because the comparison is not something a future edit can forget. ## Adjacent traps - **Mappers that skip the version.** A bean mapper configured to ignore "technical" fields, or a DTO that simply omits it, silently reduces the flow to the unprotected variant. Assert it in a test. - **Client trust.** The version is not a security control. A malicious client can send any number; the worst outcome is overwriting a concurrent edit, not privilege escalation. Never use it for authorisation, and never let a missing version mean "skip the check" — treat absent as a conflict. - **`merge` returns a new instance.** Continue working with the returned managed object; the detached argument stays detached. - **Partial forms.** Merging a detached instance copies **all** mapped state, so fields the form did not include get overwritten with nulls or defaults. Either carry the full state or use the explicit compare-then-mutate style. - **The version leaving the system.** Once clients hold it, it is part of your contract; changing its type or semantics later is a client-visible change. A plain counter travels better than a formatted timestamp. ## What to do on conflict Automatic retry is usually wrong here: the operation is "set these fields to what a human typed against the old values", and redoing it against fresh data would overwrite the other person by definition. Instead return a conflict (`409` over HTTP), reload, and show the user what changed — a diff, or at minimum "this record was modified while you were editing". For genuinely mergeable data you can attempt a field-level merge and only escalate on overlapping fields. ## Testing it The test that matters: load a record, capture its version, update the row through a second path, then submit the first version and assert a conflict. Without that test, the unprotected variant is indistinguishable from the protected one in every other check you run.