Optimistic Locking.

Interviewers love this question because it reveals whether you can stop silent overwrites without forcing everyone to wait in line.

Question: What is optimistic locking in Spring Boot, and how does Spring Data JPA use it?

Answer: Optimistic locking is a way to detect that two transactions tried to change the same row, instead of blocking one of them up front. In Spring Data JPA, you usually add a @Version field to the entity, and Hibernate checks that version when it updates the row. If someone else already changed the row, your update fails instead of silently overwriting their work.

Interview-Ready Answer: I use optimistic locking when I want to prevent lost updates without locking rows for a long time. In Spring Data JPA, I add a @Version field, and Hibernate includes that version in the UPDATE statement. If the row changed after I read it, the update affects zero rows and Spring throws an optimistic locking exception, which I can handle by retrying or asking the user to refresh. It is a great fit for read-heavy systems because readers do not block each other.

What it is

Optimistic locking is a safety check for concurrent updates. The word optimistic means the system assumes conflicts are rare, so it does not lock the row while you are reading it. Instead, it remembers a version number and verifies that the row is still the same when you write it back.

How it works under the hood

1. You add a version field to the entity, usually @Version private Long version;.
2. Hibernate reads the row and stores the current version in the entity object.
3. You edit the entity in your service layer, often inside a transaction.
4. On flush or transaction commit, Hibernate sends SQL like update product set name=?, version=? where id=? and version=?.
5. If the row still has that old version, one row is updated and Hibernate increments the version.
6. If another transaction changed the row first, the where clause matches zero rows, and JPA raises OptimisticLockException; Spring usually translates that into ObjectOptimisticLockingFailureException or OptimisticLockingFailureException.

When and why to use it

Use optimistic locking when many requests read data but only some write it, like profile edits, product administration, or order adjustments. It is especially useful when the user can reasonably retry, refresh, or merge changes. It keeps throughput high because reads do not block each other.

Do not use it as a magical cure for all concurrency problems. It protects against lost updates meaning one user overwriting another user’s change, but it does not replace transaction isolation for dirty reads or phantom reads.

Optimistic vs pessimistic locking

Performance and edge cases

The normal cost is tiny: one extra version column and one extra comparison in the UPDATE statement, so the write path stays O(1). The expensive part is conflict handling, because a failed write means another round trip and usually a retry; a common retry policy is 2 to 3 attempts with a small backoff such as 50 to 200 ms.

A few important gotchas matter in interviews. First, optimistic locking checks writes, not reads, so two users can still open the same record at the same time. Second, bulk JPQL updates and native SQL updates can bypass entity version checks unless you handle versioning yourself. Third, do not manually set the version field; the JPA provider owns it. Finally, the version value is provider-managed, so do not rely on a specific starting number; focus on the fact that it changes on update.

Memory model

Think of it like a museum ticket stub: when you leave the room, your ticket has a number, and the guard checks that the number is still current when you come back. If someone already used the latest ticket, your old one is rejected. That is the whole mental model: read freely, write carefully, verify the ticket.

Real-World Story: Imagine a checkout service for a flash-sale store. Two customers try to buy the last wireless headset at almost the same time. Both load the same inventory row, both think there is one item left, and both try to reserve it. With optimistic locking, the first update succeeds and bumps the version; the second update fails with a stale-data error instead of silently overselling the product.

In production, this usually shows up as a controlled conflict rather than a disaster. The API returns a 409 Conflict or a friendly message like 'please refresh and try again,' and the log contains a Spring exception such as ObjectOptimisticLockingFailureException. If the team misunderstands the concept and removes @Version, the bug becomes much worse: orders may both succeed, inventory goes negative, payment is captured for stock that no longer exists, and support sees angry users reporting that the site sold them an item that was already gone.

The key lesson is that optimistic locking does not prevent competition; it makes competition visible and safe.

Follow-up & Tricky Questions:

• How do you recover from an optimistic locking failure? Retry the operation only if it is safe to repeat, usually with a fresh read and a small backoff. For user edits, it is often better to reload the latest data and ask the user to merge changes.
• What is the difference between @Version and @Lock(LockModeType.OPTIMISTIC)? @Version defines the version column that makes optimistic locking work. @Lock asks JPA to use a specific lock mode for a query; the common one is still based on version checking.
• Does optimistic locking block other readers? No. Readers can still load the same row at the same time; the conflict is detected later when someone tries to write.
• Why does the exception sometimes appear only at commit time? Because JPA often checks the version when flushing SQL, and flush can happen automatically at transaction commit. Using saveAndFlush makes the failure show up earlier and more predictably.
• Can I use it with bulk updates? Not safely by default. JPQL bulk updates and native SQL can bypass the entity manager, so they can skip version checks unless you manually include version handling.
• Can the version type be a timestamp? Yes, JPA supports numeric versions and timestamp-style versions, but numeric versions are usually simpler and more common in interviews and real projects.
• Tricky: If two requests call findById at the same time, does one fail? No. Both can read the row successfully; the failure happens later when they both try to save conflicting changes.
• Tricky: If I call save() on a stale entity, will I always see the exception immediately? Not always. Without an explicit flush, the error may surface during transaction commit, so the method can look successful until the transaction closes.

Common Mistakes:

• Forgetting @Version and assuming JPA will detect lost updates automatically. Correction: without a version column, the last write usually wins silently.
• Trying to use optimistic locking to block reads. Correction: it does not block reads; it only detects conflicting writes.
• Manually setting the version field in code. Correction: let JPA manage it, or you can create false conflicts and broken updates.
• Using bulk SQL or native updates and expecting JPA to protect the row. Correction: those paths can bypass the entity manager, so version checks may not run.

Memory Hook: Read with trust, write with a ticket. You can look at the row freely, but when you write, JPA checks whether your version ticket is still the latest one.

Cheat Sheet:

• @Version is the core feature.
• Hibernate adds the version to the UPDATE WHERE clause.
• Zero rows updated means stale data.
• Spring translates the JPA error into a Spring data access exception.
• Best for read-heavy, low-contention workloads.
• Retry only when the action is safe to repeat.

Practice Tasks:

• Add a @Version field to one of your own entities and print the version before and after an update.
• Write a test that loads the same entity twice, updates one copy, then tries to save the stale copy and asserts the exception.
• Try a JPQL bulk update and observe how it differs from a normal entity update with version checking.