Loading published curriculum…

14 · Hibernate and Spring Data JPA in depth / LESSON 71 OF 102

Optimistic locking, pessimistic locking, and auditing

Concurrent updates need an explicit conflict policy so later writes do not silently erase earlier ones.

Before this lesson: Propagation, isolation, and rollback rules

Understand the topic

@Version adds an optimistic version check to updates. Two transactions loading the same version cannot both commit conflicting changes successfully. Translate a conflict into a documented response and let the caller decide whether to reload or retry.

Pessimistic locks serialize access while held and can cause deadlocks; acquire locks consistently and keep transactions short. Auditing timestamps record events but do not replace a version column. Capture actor identity from trusted context, not arbitrary request fields.

EXAMPLE · JAVA

Task version field

@jakarta.persistence.Version
private Long version;

What to expect

Add to the Task entity and create the matching version column through a migration. Concurrent stale updates raise an optimistic locking failure.

YOUR TURN

Put it into practice

  1. 01Run two transactions that read the same task and then update it.
  2. 02Commit one, observe the conflict in the other, and map it to an API conflict response.
  3. 03Verify: No update silently overwrites a newer version and the response tells the client to reload.

Pass a quiz or complete a lab to check today’s streak. Each lesson counts once per day, including when you review it later.

UNDER THE HOOD

Build the mental model

Concurrent updates need an explicit conflict policy so later writes do not silently erase earlier ones.

  1. 01@Version adds an optimistic version check to updates. Two transactions loading the same version cannot both commit conflicting changes successfully. Translate a conflict into a documented response and let the caller decide whether to reload or retry.
  2. 02Pessimistic locks serialize access while held and can cause deadlocks; acquire locks consistently and keep transactions short. Auditing timestamps record events but do not replace a version column. Capture actor identity from trusted context, not arbitrary request fields.
  3. 03Trace the example: Add to the Task entity and create the matching version column through a migration. Concurrent stale updates raise an optimistic locking failure.

A mistake worth avoiding

Two browser tabs overwrite each other without an error.

DEBUGGING ROOM

Something broke. Where do you look?

Two browser tabs overwrite each other without an error.

Before revealing the diagnosis, write down your first investigation step.

CHECK YOUR UNDERSTANDING

Does @Version prevent every concurrency conflict from occurring?

Choose one answer

BUILD IT YOURSELF

Run two transactions that read the same task and then update it.

  1. 1.Run two transactions that read the same task and then update it.
  2. 2.Commit one, observe the conflict in the other, and map it to an API conflict response.
  3. 3.Reproduce this failure, then repair it: Two browser tabs overwrite each other without an error.

Acceptance checklist

Lab completion is your self-report. Knowledge checks do not certify project quality.

RETRIEVE IT FROM MEMORY

Does @Version prevent every concurrency conflict from occurring?

Revisit this lesson in three days after a successful check or lab.

Ready for the next step?

No update silently overwrites a newer version and the response tells the client to reload.

Reading is separate from passing a knowledge check or completing a lab.

Go deeper · official references