What is optimistic locking in JPA, and how does the @Version field implement it?
answer
- version column in UPDATE ... WHERE id=? AND version=?
- 0 rows affected -> OptimisticLockException
- Spring -> ObjectOptimisticLockingFailureException
- no DB lock, detect at flush
- @Version numeric or timestamp, provider-managed
basics
~10 sOptimistic locking detects concurrent edits without locking rows. You add a @Version field; Hibernate checks it in the UPDATE's WHERE clause and throws an error if another transaction already changed the row.
solid answer
~40 sOptimistic locking assumes conflicts are rare, so it takes no database lock. You annotate a numeric or timestamp field with jakarta.persistence.@Version. When an entity is updated, Hibernate emits UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?. If another transaction already committed a change, the version no longer matches, zero rows update, and Hibernate throws OptimisticLockException — which Spring Data translates to ObjectOptimisticLockingFailureException. This lets you catch the conflict and retry or surface it to the user. It costs one extra column and no lock contention, so it scales well for low-conflict, read-heavy workloads. The version field is managed entirely by the provider; you never set it manually.
code
java · 15 lines@Entity
public class Account {
@Id
private Long id;
@Version // Hibernate manages this; never set it manually
private Long version;
private BigDecimal balance;
}
// On save() Hibernate runs:
// UPDATE account SET balance=?, version=? WHERE id=? AND version=?
// If 0 rows update -> OptimisticLockException
// -> Spring ObjectOptimisticLockingFailureExceptiongo deeper
Know that @Version adds a column checked in the UPDATE WHERE clause and an exception is thrown on conflict.
Explain the exact SQL, the 0-rows-affected mechanic, and the Spring exception translation.
Discuss detached-entity/merge conflict detection, allowed version types, and read-heavy scaling rationale.
Frame optimistic vs pessimistic as an architectural default; tie version bumps to aggregate consistency boundaries.
## What problem it solves When two transactions read the same row and both write it back, the second write can silently overwrite the first — the *lost update* problem. **Optimistic locking** prevents this without holding any database lock: it *assumes* conflicts are rare and only *detects* them at write time. ## The @Version field You add a field annotated with `jakarta.persistence.@Version` (older code: `javax.persistence.@Version`): ```java @Entity class Account { @Id Long id; @Version Long version; // managed by Hibernate, never set by you BigDecimal balance; } ``` Allowed types: `int`/`Integer`, `long`/`Long`, `short`/`Short`, `java.sql.Timestamp`, or `java.time.Instant`/`LocalDateTime` (Hibernate). Numeric versions are preferred — timestamps have resolution problems under high concurrency. ## How the check works On every flush of a *dirty* entity, Hibernate generates: ```sql UPDATE account SET balance = ?, version = ? WHERE id = ? AND version = ? ``` The `version` in the SET is the current value + 1; the `version` in the WHERE is the value that was loaded. The JDBC driver returns the **row count**. If it is `1`, the update succeeded. If it is `0`, some other transaction already committed a newer version, so the WHERE matched nothing → Hibernate throws `org.hibernate.StaleObjectStateException`, wrapped as JPA `jakarta.persistence.OptimisticLockException`. ## Spring's exception translation Because Spring Data repositories sit behind `PersistenceExceptionTranslationPostProcessor`, the provider exception is translated into Spring's `org.springframework.orm.ObjectOptimisticLockingFailureException` (a subclass of `DataAccessException`). Catch that in your service to retry or report a conflict. ## When it fires - Only when the entity is actually **modified** (dirty) and flushed, *unless* you explicitly request an `OPTIMISTIC` lock (which forces a version check even for read-only entities). - The check happens at **flush/commit**, not at read time. Two transactions can both read version 5; the first to commit wins, the second gets the exception. ## Gotchas - **You must not set `version` yourself** — the provider owns it. Manually mutating it breaks the mechanism. - **Detached-entity merges**: if you send an entity to a web client and merge it back, include the version so stale submits are caught (this is how you get browser-tab-level conflict detection). - **No `@Version` field = no optimistic locking**, and requesting `LockModeType.OPTIMISTIC` on a repository method for such an entity throws an exception. - The version column should have a NOT NULL default handled by JPA; a null version on a new entity is fine (it starts at 0/1). ## When to use Default choice for most web CRUD: low write-conflict rates, no lock held across user think-time, horizontally scalable. Switch to pessimistic locking only when conflicts are frequent or a business invariant must be serialized at the DB.
- At what point does the OptimisticLockException actually get thrown?At flush/commit — when Hibernate emits the versioned UPDATE and the driver reports 0 rows affected. Not at read time. That's why two transactions can both read version 5 and only the second committer fails.
- Which Spring exception wraps the JPA OptimisticLockException, and why does that matter?org.springframework.orm.ObjectOptimisticLockingFailureException, a DataAccessException subclass produced by Spring's persistence-exception translation. It matters because you catch the Spring type in your service layer to implement retry logic, staying decoupled from the JPA/Hibernate API.
saying these in an interview costs you the question
- Thinking @Version takes a database lock (it doesn't — no lock is held).
- Saying the conflict is detected at read time rather than at flush/commit.
- Claiming you must increment the version field manually in code.
- Believing optimistic locking blocks other transactions from writing.