How would you prevent lost updates with @Version in a Spring API?

Carries an original version through an API update and turns an optimistic-lock failure into an explicit conflict workflow.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I add a @Version field to the entity and return its current value with the representation. The client sends the version it edited, either in the command body or an HTTP precondition such as If-Match. Inside a transaction I load and authorize the current entity, compare its version with the client's original version, and only then apply allowed changes. Hibernate includes the managed version in the update, so a writer that commits after that check still causes an optimistic-lock failure that the API maps to a conflict response.

Full answer below

Practice focus

Version predicates, detached clients, HTTP conflict contracts, retries, authorization, and concurrent integration tests.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
A version field works only when the client's original version participates in the eventual update decision.
I add a @Version field to the entity and return its current value with the representation. The client sends the version it edited, either in the command body or an HTTP precondition such as If-Match. Inside a transaction I load and authorize the current entity, compare its version with the client's original version, and only then apply allowed changes. Hibernate includes the managed version in the update, so a writer that commits after that check still causes an optimistic-lock failure that the API maps to a conflict response.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The conflict response gives the client enough information or a link to reload and decide whether to merge, retry, or discard changes. The server must not simply replace the original version with the newly loaded version, because that turns the operation back into last-write-wins. Automatic retry is suitable only when the command can be safely reevaluated against current state and preserves user intent. Delete-versus-update and authorization changes need deliberate outcomes too.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Loading the latest version and overwriting the client's token.
Returning 500 for every expected concurrency conflict.
Automatically retrying a human edit without reevaluating intent.

How would you prevent lost updates with @Version in a Spring API?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue practice

Try a variant

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?