'optimistic locking optimistic concurrency control
As I learned that "optimistic locking" that sometimes referred "optimistic concurrency control", doesn't really have a lock. A typical implementation is CAS (Compare-And-Swap). So I wonder without locking, why this is still called "optimistic locking"? Is there any historical reason because this term was originated from database world?
Solution 1:[1]
As you rightly pointed, the transaction wont acquire any lock on the row/persistent object it tries to update. But, as you might also aware that Optimistic locking works on the principle of Versioning. Meaning...The database-table-record's version column(if you have set it) will be incremented each time it gets updated by a transaction. Also, any transaction which tries to update a particular record need to compare record's version number at the time of retrieval with record's version number at the time of updating. Its similar to having a key(as in Lock-Key) called version number and trying to see if it matches..if matches what is in the database(means..the record is not updated by another tx meanwhile), after which you would perform an update. If match fails(record updated by another tx..and your key wont work anymore).
Hence, Versioning/Opt Locking appears as if you have a key(called Version) for a virtually non existing lock. And the real meaning of lock can be understood in the situation when your current version of the record fails to match and PREVENTS(means LOCKED) you to update the record.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Community |