The difference between optimistic concurrency control and pessimistic concurrency control

Pessimistic concurrency control
A locking system that prevents users from modifying data in a way that affects other users. If a user performs an action that causes a lock to be applied, only the owner of the lock releases the lock, and other users can perform actions that conflict with the lock. This approach is called pessimistic concurrency control because it is used primarily in environments where data contention is intense, and in environments where the cost of protecting data with locks is lower than the cost of rolling back transactions when concurrent conflicts occur.
Optimistic concurrency control
In optimistic concurrency control, data is not locked when the user reads the data. When a user updates the data, the system checks to see if the user has changed the data after reading the data. If another user updates the data, an error occurs. In general, the user who receives the error message rolls back the transaction and starts over again. This approach is called optimistic concurrency control because it is used primarily in environments where data contention is not large and the cost of occasionally rolling back transactions is lower than the cost of locking data when reading data.
Specific differences and examples illustrate the following:

Pessimistic concurrency control: Assuming that A and B need to modify the same file on the SCC (Source Control), when a locks the file and modifies it, B cannot modify the file, he can only wait for a to unlock the file before he can modify it. This shows that pessimistic concurrency control is to emphasize control in the front, to ensure that the entire process does not appear file version of the conflict. This can result in system efficiency loss on the locking mechanism, especially when the locking mechanism needs to use low speed external storage (such as filelocking), but doing so reduces the concurrency of the transaction, especially if there is no conflict between the transactions. For example, when a modifies the data, B can only wait.

Thus, pessimistic concurrency control incrementally synchronizes each transaction by using an explicit lock mechanism or timestamp. If the cost of locking mechanism is higher, pessimistic concurrency control will appear some drawbacks. The first is the problem of efficiency, especially when using inefficient external storage systems to implement the locking mechanism. Second, in transactions that do not conflict (for example, read-only transactions), it is unnecessary to use the lock mechanism, which can only increase the system load. Again, this approach reduces the concurrency of the system.

Optimistic concurrency control: also assuming that A and B need to modify the same file on the SCC, they have to get this file to their own machine, a modified after the file uploaded to the SCC, then B also modified, when he also plans to upload the file, the system will inform B, has been uploaded, and a mistake. The rest of the problem can only be solved manually by B, for example, B may copy the changed contents of the file again in the SCC. Optimistic concurrency control makes system efficiency loss in the post-processing of transactions, such as B must manually modify the things he has modified, but this control method in a very small number of conflicts in the multi-transaction processing appears to be very efficient.

Optimistic concurrency control divides the transaction into three phases: The reading phase, the verification phase, and the write phase. In the read phase, transactions write data to the local buffer (as described above, A and B take the files to their own machine, and there will be no checksums at this point, and all transactions will be verified synchronously during the verification phase (for example, when a or b is intended, but not yet, when the changed file is written to the SCC). ; During the write phase, the data is eventually submitted. After the read phase is complete, the system assigns a timestamp to each transaction.

A common problem with pessimistic concurrency control is deadlock. For example A in the modification file T1,b in the modification file T2, they locked the two files, assuming T1 and T2 content, b in the modification of T2 found that he also need to modify the T1, but T1 was a lock; at the same time, a change T1 also found that he also needs to modify the T2, But T2 was locked by B, so there was a deadlock. Of course, in practice, this situation can be solved by a and B, but in a complex transaction environment, deadlocks make the problem very complicated.

Reference Link: https://www.cnblogs.com/Fandyx/archive/2012/07/14/2591153.html