Database - optimistic and pessimistic locking

EDITORIAL:

Lock Depending on how their use can be divided into: optimistic and pessimistic locking. That optimistic lock optimistic concurrency control, pessimistic locking that is pessimistic concurrency control, they are dealing with concurrency control techniques mainly used. Among them, it is the pessimistic locking mechanism locks the database itself provides implementation.

Pessimistic locking:
pessimistic locking (Pessimistic Concurrency Control) abbreviated as PCC. Understood from the literal sense, that is, every time the data are considered to get others will modify, so every time she took the data will be locked, so that others will want to take this data into the block until it got the lock. In a traditional relational database inside to use a lot of this locking mechanism, such as row locks, table locks, etc., read lock, write lock, are locked before doing the first operation.

It prevents a transaction to affect other users modify the data. If the operation is performed in a transaction data for a particular application of a lock, then the lock is released only when the transaction, other transactions will be able to perform operations and lock the conflict.

Pessimistic locking is mainly used in data highly competitive environment, and if concurrency conflicts occur, the cost of the transaction is lower than the lock to make the case rollback of a transaction.

Lock optimistic:
optimistic locking (Optimistic Concurrency Control) abbreviated as OCC, understood in a literal sense, each time to pick up data when they are that others will not be modified, so it will not be locked, but when the update will be a judgment in this others did not go there during the update this data. With respect to the pessimistic locking, optimistic locking in dealing with the database, the database will not be used to provide a locking mechanism, GENERAL optimistic locking way is to record data version.

So what is the version of the data? It is to increase the data a version identifier, the read values ​​when read together with the version identifier of the data updated every time, the version identification will be updated. When we submit the updated data, the identification information to determine the current version of the database table corresponding version compared with the first identification information, if they are equal, it will update, if not equal, is considered outdated data. For example: using an auto increment integer version as the data, such as data version 2, version = 6 + 1 updated at the time of filing, compared with the version = 7 and the beginning version + 1, if they are equal, updates, if not same, the data is outdated, that other threads may be updated before.

Optimistic locking is suitable for the types of applications to read, so you can improve throughput if the database provided similar write_condition optimistic locking mechanisms are actually provided like.

Case in point:
as a financial system, when a staff member reads the user's data and make changes in the read-out of user data base (such as changing the user account balance), if pessimistic locking mechanism, which means that the entire During operation (reading data from the operator, began to modify commit changes until the results of the whole process), the database record is always in the locked state, so that if there are thousands, tens of thousands of pieces of concurrent transactions to be processed, it will affect users the efficiency of use.

When and if you use optimistic locking, then read out the data, read together this version, when after the update, this version number +1. In this case, the data will be presented with the version of the current version of the database table data corresponding to the information recorded for comparison.

User account information for the above modification example, it is assumed that the account information in the database table has a version field, a current value of 1; field and the current account balance (Balance) $ 100.

A staff 1 to read out this time (version = 1), 100-50 and deducted from the account balance).

2 A during the operation of the staff, the staff B also reads the user information (version = 1), 100-20 and deducted from the account balance).

3 A staff completed the revision of the data version number +1 (version = 2), together with the account after deducting the balance (balance = 50), committed to the database update, this time due to submit data version = +1 database records current version, the data are updated, the database record is updated to version 2.

4 Staff B operation is completed, the version number will be +1 (version = 2) attempting to submit data (balance = 80) to the database, but this time the database records than find the version, the version number of the data filed employee B 2, the current version of the database record + 1 = 3, 2 is not equal to 3, and therefore, the staff B submission was rejected. Thus, it is possible to avoid the operation cover B staff employee A result of using the modified results based on the old data version = 1.

Guess you like

Origin www.cnblogs.com/dbalightyear/p/11237085.html