# Distributed Transaction (Continue...) ![left](./student-guide/diagram/03-distributed-02-01.png) + Write column: When a user writes a row of data, if the row is less than 255 bytes in length, it is stored in the write column; otherwise, the row is stored in the default column. + Default column: Used to store data that is more than 255 bytes long. ------------------------------------------------------------ Suppose we want to transaction the following: ``` Begin < 1，Tom > -> < 1，Jack > < 2，Andy > -> < 2, Candy > Commit; ``` Note: Assume that key = 1 and key = 2 are in different TiKV regions. First, at the beginning of the transaction, we get a startTS from the PD. Assuming 100, we enter the first stage of Percolator PreWrite. At this time, since there is no commit, we need to write the Lock and Default column family (CF). As can be seen from the figure, writing When you enter Default, we add a timestamp to the key (startTs), and the values of the two modify Lock column family (CF) are not quite the same, mainly including lock type and startTs. As shown below: ``` Key = 1 Default CF Lock CF Write CF key value key value key value 1_100 Jack 1 W, primary key,100... Key = 2 Default CF Lock CF Write CF key value key value key value 2_100 Candy 2 W, @ key = 1,100... ``` (W: for write, D: for delete) One important point here is that we modify key = 1 and key = 2 in the transaction. In the Lock column family (CF), we only use the first modify, that is, key = 1 as the primary key, and the lock with key = 2 points to key = 1. (i.e., the value in the Lock column family (CF)) At the same time, we also note that the Default column family (CF), whether modify or deleting data, is a new key-value pair, rather than modify or deleting the stored data, which will be introduced later when MVCC technology is introduced. Next, we go to the second stage of Percolator Commit. At this time, we will get a commitTS from the PD, assuming 110, and then write it in the Write column family (CF), the key plus the timestamp (commit_ts), and the value is the startTs of this transaction , the primary key of the Lock column family (CF) record was deleted. As shown below: ``` Key = 1 Default CF Lock CF Write CF key value key value key value 1_100 Jack 1 W, primary key,100... 1 D, primary key,100... 1_110 start_ts=100 Key = 2 Default CF Lock CF Write CF key value key value key value 2_100 Candy 2 W, @ key = 1,100... 2 D, @ key = 1,100... 2_110 start_ts=100 ``` (W: for write, D: for delete) After the Commit phase is completed, when we want to read the data, we will find that whether key = 1 or key = 2, we only need to find out if there is a lock in the corresponding Lock CF. If there is no lock or the lock is deleted (flag D), it can be read, otherwise the read will fail. Finally, we found that during the commit phase of Percolator, we only had to delete a primary key with key = 1, because the lock CF with key = 2 stores a pointer to the primary key with key = 1. Suppose, if in the commit stage, only key = 1 is deleted due to an error, and there is no time to delete key = 2, after recover, when key = 2 is read, it is found that there is a lock on the Lock CF (because the error is not deleted) pointing to key = 1, and the lock corresponding to key = 1 has been deleted, we Knowing that there was not time to update (remove) the lock for key = 2 before the error occurred, but in fact the transaction was committed successfully. As a result, the problem of distributed transaction mentioned earlier is solved. We have only briefly introduced the Percolator model here, the actual implement will be complicated, and we have overlooked some details. If you want to know more, you can refer to the content in the Distributed transaction course.