Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: tidb 在悲观锁模式下的流程
May I ask, in TiDB’s pessimistic transaction mode, the commit process is the same as in the optimistic transaction mode. Is it still necessary to perform write-write conflict detection and lock conflict detection during the prewrite phase?
Assuming a row of data is locked when executing the begin; update statement in pessimistic transaction mode, other transactions cannot modify this row. In this case, is it still necessary to perform write-write conflict detection and lock conflict detection when the pessimistic transaction is committed?
In pessimistic mode, data is locked during the DML stage, before the 2PC. In optimistic mode, conflict detection occurs after you execute the commit operation, during the first phase of 2PC, which is the prewrite phase.
In pessimistic mode, there is conflict detection during the DML phase, but after commit, the process is the same as in optimistic mode.
The operation process after executing commit in pessimistic transactions is the same as in optimistic transactions, but my question is, in pessimistic transaction mode, is it unnecessary to perform write-write conflict detection and lock conflict detection after executing the commit operation? This way, performance can be slightly improved.
Currently, it should be reusing the same set of code after commit.
Personally, I believe the transaction commit process for this pessimistic lock can still be optimized.
If the issue is resolved, you can mark the corresponding answer as “Best Answer”~
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: Raymond
|
username: 
|
username: 
|
username: 
|
username: