Optimistic Locking
OptimisticLocking assumes you will be the only one changing the target. If there is a transaction conflict, the conflict could be resolved in one of several ways:
- You could lose.
- You could merge.
- You could win, causing the previous one to lose.
- Etc.
Here is the definition I've always heard for OptimisticLocking (versus PessimisticLocking):
OptimisticLocking resolves change conflicts at the very last moment. It accomplishes this by comparing the "Load Set" of each participant with the "Store Set" of that participant. The "Load Set" enumerates the specific records that the transaction in question has read and the most recent time that they were read. The "Store Set" enumerates the specific records that the transaction in question has written (or changed, depending on the system) and when they were modified. The transaction commit then proceeds as follows, for each entry in the store set:
- If the record is not contained in any other active store sets, the transaction commits.
- If the timestamp of the most recent of the other active stores precedes the timestamp of the entry in the current transaction's load set, the transaction commits.
- For each competing store record whose timestamp exceeds the corresponding load set entry, the contents are compared with the record in the current transaction's store set. If they differ, the caller of the current transaction is notified and the current transaction is either restarted or aborted.
The effect of this is to delay locking to the last possible moment. The choice between OptimisticLocking and PessimisticLocking (and there are some other intermediate approaches) includes the following considerations:
- The cost of the computation (in time, money, or whatever)
- The likelihood of conflict
- The cost of abort/restart