Optimistic locks and pessimistic locks, optimistic locks pessimistic locks

Optimistic locks and pessimistic locks, optimistic locks pessimistic locks

Locking)

This concept has been touched upon when we learned multithreading. In fact, the lock here and the concurrent lock processing in multithreading are a truth. They all violently classify resources as their own. Here, we use locks to ensure that some data is not modified by the outside world during an operation. Such a mechanism is called a "Lock" here ", that is, lock the selected target data so that it cannot be modified by other programs.
Pessimistic Locking depends on the Data mechanism.
Pessimistic lock, just like its name, is used for the database, and the database is pessimistic. He feels that every program operated on him may produce concurrency. It refers to a conservative attitude towards data being modified by the outside world (including other current transactions of the system, as well as transactions from the external system). Therefore, throughout the data processing process, lock the data. Pessimistic locks often rely on the locks provided by the database (and only the locks provided by the database layer can truly guarantee the exclusive data access; otherwise, even if the locking mechanism is implemented in the system, it cannot be ensured that the external system will not modify the data ).
A typical pessimistic lock call based on the database (with forupdate added ):

Select * from account wherename = "Erica" forupdate

This SQL statement locks all records that meet the search criteria (name = "Erica") in the account table. Before the transaction is committed (the lock in the transaction process will be released when the transaction is committed), these records cannot be modified by the outside world.

Optimistic Locking)

Compared with pessimistic locks, optimistic locks adopt a more loose locking mechanism. Pessimistic locks are implemented by the database lock mechanism in most cases to ensure maximum operation exclusiveness. However, there is a large amount of database performance overhead, especially for long transactions, which is often unbearable. The Optimistic Locking Mechanism solves this problem to some extent. Optimistic locks are mostly implemented based on the data Version record mechanism. What is the data version? Add a version ID for the data. In the database table-based version solution, you can add a "version" field to the database table.

For example, in a financial system, when an operator reads user data and modifies it based on the read user data (such as changing the user account balance), if a pessimistic lock mechanism is used, this means that the entire operation has been

The database record is always locked during the process (from the operator reading data, starting modification to submitting modification results, or even the time when the operator goes to coffee preparation ).

Hundreds of thousands of concurrent jobs. The Optimistic Locking Mechanism solves this problem to some extent. Optimistic locks are mostly implemented based on the data Version record mechanism. What is the data version? Add a version ID for the data. In the database table-based version solution, you can add a "version" field to the database table.

When reading the data, read the version number together, and then add one to the version number when updating the data. In this case, compare the version data of the submitted data with the current version information recorded in the database table. If the submitted data

If the version number is greater than the current version number of the database table, it is updated. Otherwise, it is considered as expired data. For the above example of modifying user account information,

Assume that the account information table in the database has a version field. The current value is 1, and the current account balance field (balance) is $100.

1. Operator A reads it (version = 1) and deducts $50 ($100-$50) from its account balance ).

2. During operator A's operations, operator B also reads this user information (version = 1) and deducts $20 ($100-$20) from its account balance ).

3. Operator A completes the modification and submits the data version plus one (version = 2), along with the account balance after deduction (balance = $50) to the database for updates, at this time, due to the large version of the submitted data

The current version is recorded in the database, the data is updated, and the version of the database record is updated to 2.

4. When operator B completes the operation and tries to submit data (balance = $80) to the database by adding version 1 (version = 2), it finds that, the version number of the data submitted by operator B is 2, and the current version of the database record is 2, which does not meet the optimistic lock policy of "The submitted version must be later than the current version to be updated". Therefore, the submission of operator B is rejected.

This avoids the possibility that operator B overwrites operator A's operation results with the old data modification Result Based on version = 1.

From the above example, we can see that the Optimistic Locking mechanism avoids the database lock overhead in long transactions (no database data lock is applied during operator A and operator B operations ), greatly increased the number of concurrent connections

Overall performance.

It should be noted that the optimistic lock mechanism is often based on the data storage logic in the system, so it also has certain limitations. In the above example, because the optimistic lock mechanism is implemented in our system, users from external systems

The balance update operation is not controlled by our system, so dirty data may be updated to the database. In the system design phase, we should fully consider the possibility of these situations and make appropriate adjustments (such

The Optimistic Locking policy is implemented in the database stored procedure. It only opens the data update path based on the stored procedure, rather than making the database table public ).