# Tidb Database Pessimistic Lock (Continue...)


![left](./student-guide/diagram/12-pessimistic-locking-02-01.png)

------------------------------------------------------------

Having understood the transaction flow of the TiDB database, we found a problem that our locks were added at the commit stage of the transaction. That is, until the start of the transaction and the transaction commit time, we do not perform lock detection. During this time, every row of the default transaction has no lock, and the operation will succeed. Version information and lock information are only checked upon submission. This strategy is called optimistic locking. It has a feature that a transaction is never rolled back due to a lock conflict during execution, but it is possible to find a collision rollback at the time of commit. Imagine a long transaction that was executed for 20 minutes and only found a conflict at the time of submission, rolled back, and the previous 20 minutes of operation were done in vain.

Corresponding to optimistic locking is pessimistic locking, which is characterized by the fact that every row (add, delete, change) in a transaction is immediately locked, so if it is found that the row has been locked or modify by another transaction at the time of locking, the transaction will block or roll back. The benefit of this is that conflicts can be detected as soon as the transaction is running.

TiDB implement pessimistic transactions in a smart and elegant way. We carefully thought about the Percolator model and found that, in fact, we only need to modify the behavior of 2-phase commit when the client calls Commit, and advance the first stage lock and lock to the process of executing DML in the transaction is not OK, like this: