Optimistic Locking

Optimistic Locking is another way concurrency control mechanism that assumes conflicts are rare and allows multiple transactions to proceed without acquiring locks during the transaction's execution. Instead of locking resources, it detects conflicts at the commit time. If a conflict is detected (for example, another transaction has modified the data), the transaction is rejected and must be retried.

Optimistic Locking typically follows these three phases,

1. Read phase, in this phase a transaction reads data without locking it, and along with reading, it also maintains a version number or a timestamp associated with the data, not worrying if its being read by some other transaction or not.

2. Validation phase (before commit), just before committing, the transaction checks if the data has been modified by another transaction. This is done by comparing the current version/timestamp of the data (in the database) with the original version/timestamp read in the read phase.

3. Write phase (commit), if no conflicts are detected, the transaction proceeds to update the data and increment the version and if a conflict is detected (data was modified), the transaction is rolled back and retried.

Simple right! lets just to actually implementing it. So for database implementing optimistic locking, they maintain some identifier (which identifies the updates) for our case say our database maintains version column (check OptimisticEmployees).

Now transaction A on read phase, reads this data along with the version number,

SELECT id, salary, version FROM Employees WHERE id = 1;

Say, while transaction A is performing some application processing on that data, and meanwhile, transaction B updates the same row and increments version.

UPDATE Employees SET salary = 6000, version = version + 1 WHERE id = 1 AND version = 1;

Now, transaction A assumes the data version should not have been updated, tries to do this below query,

UPDATE Employees SET salary = 5500, version = version + 1 WHERE id = 1 AND version = 1;

Here, as the version is already updated by transaction B, the update fails (because the condition version = 1 is no longer true), and transaction A must retry. If the version wouldn’t have changed, the update should have succeeded.

Similar to version, we could also have use timestamp column similarly (such as updated_at), or instead of using version or updated_at, some systems use a checksum of the row's data. Before updating, the system compares the original checksum with the current checksum to detect changes.

Many modern ORM (object-relational mapping) tools provide built-in support for optimistic locking, which simplifies implementation. For example, in Hibernate (Java), adding a @Version annotation on a version field enables automatic version checks during updates. Similarly, in Django ORM (Python), developers can manage a version or updated_at field and manually check for changes before saving. This abstraction makes it easier to adopt optimistic locking without writing custom version control logic.

🌟 The advantage of optimistic locking, no deadlock! as there is no such locking involved at the database level.

Optimistic locking is good for low-contention, high-concurrency (as there is no locking, which slows down the transactions due to blocking), highly scalable systems like distributed databases or APIs. Also, locking is complex and expensive for distributed systems, so optimistic locking is suggested.

However, it is optimal when conflicts are rare, such as read-heavy systems where updates are infrequent and in high-contention environments, where multiple transactions frequently update the same data, it can be too costly as it can lead to many failed commits and retries.

I just want to give you a little bit information regarding conflict resolution,

When a conflict is detected in optimistic locking, the system must decide how to handle it. The most common strategy is to simply retry the transaction after re-reading the latest data. In some cases, especially in user-facing applications, the system might notify the user about the conflict and ask them to reload or merge their changes. Some advanced systems implement automatic merge strategies, where non-overlapping changes from conflicting transactions can be combined safely without user intervention.

Conclusion

While optimistic locking works well in low-conflict, high-concurrency systems, it may not be suitable for all situations. In applications involving critical, high-stakes operations (like financial systems, ticket booking, or inventory management), where lost updates or frequent retries could lead to data integrity issues or poor user experience, pessimistic locking is a safer choice. In such systems, proactively locking resources to prevent concurrent updates ensures data correctness, even if it comes at the cost of reduced concurrency.

Aspect	Optimistic Locking	Pessimistic Locking
Conflict Assumption	Assumes conflicts are rare.	Assumes conflicts are likely.
Locking Approach	No locks are held during reads instead conflicts are detected at commit time.	Locks are acquired during reads and writes to prevent conflicts.
Concurrency	Higher concurrency, better for low-conflict scenarios.	Lower concurrency due to blocking.
Deadlocks	Not possible.	Possible, requires deadlock's detection and resolution.
Performance	Better for distributed and read-heavy systems.	Better for high-conflict and write-heavy systems.
Complexity	Requires conflict detection and retry logic.	Simplifies conflict detection but can block transactions.
Isolation Level	Often used in eventual consistency systems.	Often used for strict consistency systems.