Ch. 8 · Spring Boot

Spring JPA Optimistic Locking and Conflicts

Spring JPA Optimistic Locking and Conflicts. Learn the reasoning, a practical example, common mistakes and an interview exercise.

~2 min readintermediateupdated Oct 3, 2026

Version-based optimistic locking detects concurrent modifications rather than silently letting the last writer overwrite earlier changes.

Before you start

You should know Java classes, dependency injection and basic HTTP requests. Identify where a call crosses a framework-managed boundary. The snippets illustrate a focused mechanism; database configuration, application wiring and authentication must be supplied by the surrounding application when applicable.

The practical goal is to reason through this situation: Two editors load one version; the second stale save fails after the first commits. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.

Step-by-step walkthrough

Step 1: Capture the loaded version

Both editors initially read the same record version.

Step 2: Check version on save

The first committed edit advances the version; a stale second edit must conflict.

Step 3: Respect user intent

Return a conflict for reload or merge rather than silently retrying an obsolete user edit.

Worked scenario

Two editors load one version; the second stale save fails after the first commits.

Editor A changes quantity while B changes address from an earlier version. Automatically retrying B’s full stale record can overwrite A’s quantity. Version checking exposes that conflict so the application can choose field-level merging or ask the user to reload under an explicit policy.

Common mistake

Automatically retrying a user edit can overwrite intent if conflict resolution is not defined.

Verify the behavior

Save two copies in sequence and assert the stale save conflicts without losing the first change.

Interview exercise

Return a useful conflict outcome.

Answer and reasoning

Report the conflict and let the client reload or merge deliberately; retry only operations whose semantics remain valid.

Continue learning

Compare the scenario with the Spring Boot interview questions and test your understanding with the Spring Boot MCQs. For terminology and implementation details, consult the reference material.

More in Spring Boot

read ✓Spring Boot · hard

Spring @Async and Executor Configuration

Run methods asynchronously with @Async, configure a bounded executor, and handle exceptions and the proxy boundary.

~2 min readread →
read ✓Spring Boot · hard

Spring Boot Caching Abstraction

Cache method results with @Cacheable, choose keys and TTLs, and evict on writes without the self-invocation trap.

~2 min readread →
read ✓Spring Boot · hard

Spring Declarative HTTP Clients

Define outbound HTTP as an annotated interface with @HttpExchange, create the proxy, and configure timeouts and errors.

~2 min readread →
esc