Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: [课程问题] TiDB 数据库核心原理与架构 [TiDB v6] ：TiKV-分布式事务
Video lesson at 46:06
Assume that when transaction two is not committed, it wants to modify the id equal to 1. It first goes to write_cf and sees put<1_100,100>, then goes to lock_cf and finds a lock, so it cannot modify.
Why not directly go to lock_cf to check if there is a lock? If there is no lock, can’t it directly write to default_cf or write to write_cf if it is less than 255 bytes?
To modify id=1, you need to first retrieve the data, then find the target data, and check the TSO of the initiated data. To see if there have been any modifications between the initiation of the modification action, you need to check the lock information because write operations require an exclusive lock.
For reading, you also need to first retrieve the data, find the target data, and check the TSO of the initiated data to find the most recent version of the data. Even if there are modifications between the initiation of the modification action, if they haven’t been committed, they shouldn’t be read. Read operations do not require an exclusive lock resource.
This is my personal understanding.
In other words, although the modification command has obtained the TSO given by PD and the corresponding region of TiKV, it may not be able to determine exactly where the data is. Retrieving the write can retrieve all the keys of the data in this region, so it first confirms whether the data it needs is indeed there, and then searches for the lock information.
This topic was automatically closed 1 minute after the last reply. No new replies are allowed.
|
username: 箱子NvN
|
username: 
|
username: