Pessimistic locking
When we want to modify the data to a database in order to avoid the same time be modified by other people, the best way is to direct the data locked to prevent concurrent. This locking mechanism locked by the database before modifying the data, and then modify the manner referred pessimistic concurrency control (PCC).
The reason is called pessimistic locking, pessimistic because have to modify the way data concurrency control, that the probability of concurrent modification of data is relatively large, so you need to lock before modifying.
Pessimistic concurrency control in fact "take the first lock, then access the" conservative strategy, to provide a guarantee for the security of data processing.
In terms of efficiency, processing database locking mechanism will result in additional costs, there will be the possibility of a deadlock. Reduce parallelism, if a transaction locks a row of data, other transactions must wait for the transaction is processed before it can be processed rows of data.
Implementation pessimistic locking: pessimistic locking implementation, relying lock mechanism provided by the database. In the database, pessimistic locking process is as follows:
- Before modifying the data, try increasing the exclusive lock.
- Lock failure means that the data is being modified to wait or throw an exception.
- Locking success, modify the data, commit the transaction, the lock is released.
- If we lock success, there are other threads into the operation of the data or add exclusive lock operation, can only wait or throw an exception.
Optimistic locking
Optimistic locking is relatively pessimistic locking in terms of optimistic locking assumption does not create a conflict under normal circumstances data, so be time to submit updated before formal conflict or not the data is detected in the data.
With respect to the pessimistic locking, when the database for processing, do not use optimistic locking lock mechanism provided by the database, usually increases the version parameter, the data recorded version
Optimistic concurrency control believe that the probability of competition between transaction data is very small, and therefore operate as directly as possible, submitted in time to lock it, without any lock and deadlock.
Try to get started
Based MySQL InnoDB engine
Use pessimistic locking
begin;
select quantity from products where id = 1 for update; update products set quanntity = 2 where id = 1; commit;Above, the id of the product 1 modifications to be locked for update by the way, and then modify. Typical pessimistic locking strategy.
If you modify the logic of inventory occur concurrently, at the same time only one thread can open transaction and obtain a lock id = 1, other transactions can only be executed after this submission, etc., so you can ensure that data is not modified by other transactions.
Use exclusive locks will lock the data, but need to pay attention to some basic level lock, MySQL InnoDB the default row-level locking. Row-level locking is based on an index, if a SQL statement is not less than the index row-level locking, use table-level lock to lock the entire table.
Use optimistic locking
select quantity from products where id = 1 update products set quantity = 2 where id = 1 and quantity = 3First check the current inventory stock list, and then update the data table when determining the quantity and the corresponding data for the first time taken out are the same, the same update, otherwise considered stale data.
Such implementation has a problem, remove thread 1 from the database quantity is 3, the thread 2 is also taken in the same data quantity, operation, becomes 2, and then perform certain operations into a 3, then updates the thread 1 Successful operation. But the process in question.
The introduction of version parameter, optimistic locking in each data modification operations, will bring the version number, once the version number and the version number of the same data can be modified to perform operations and version to +1, otherwise it fails.
In this way realize there is a problem, if there really is a time of high concurrency, only one thread can modify successful, there are a lot of failure.
If your application is complicated by the presence of ultra-high, so resolve not good, because it will allow users to always perceived failure.
Try reducing the optimistic locking efforts to maximize throughput.
update products set quantity = quantity - 1 where id = 1 and quantity - 1 > 0Use this SQL statement, in the implementation process, queries the value of the quantity again at an atomic operation, and minus 1.
Description of difference
- Not really optimistic locking lock, high efficiency, but efforts to control the locks.
- Pessimistic locking depends on a database lock and inefficient.
to sum up
Either pessimistic or optimistic locking lock, the concept of people are out of the definition, it can be considered an idea.
We have to remember that the lock mechanism must take effect oh in the transaction.
These are my little basis for optimistic locking and pessimistic locking practice, and we hope to further in-depth understanding of understanding.