In TiDB, is data read during transaction execution a current read or a snapshot read?

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: tidb 事务执行过程中读数据是当前读还是快照读?

| username: Raymond

May I ask, when TiDB executes a transaction, does it need to first read the data involved in the transaction from TiKV into the memory of the TiDB server? When reading data from TiKV, my understanding is that it is a current read (directly reading the latest data) and does not need to be judged based on start.tso. However, the official documentation states that during a transaction:

  1. TiDB retrieves the data corresponding to the start_ts version from TiKV.

Is this statement referring to a simple read-only transaction, or is it a write transaction where data is read first and then modified? My understanding is that in a write transaction in TiDB (such as an update), when reading data, it should be a current read (locking and reading the latest data) and does not need to be judged based on start.tso. Is my understanding correct?

| username: xfworld | Original post link

Whether it is optimistic transactions or pessimistic transactions, whether it is read requests or write requests, they can all occur at the same point in time. This can lead to issues:

  1. When reading, the value is X. Should it remain consistent when writing?
  2. When writing, the value is X. Should it remain consistent when reading?
  3. Since there are N requests, they may fall on the same point in time or adjacent points in time, requiring the retrieval of the latest valid value within the time period.

Because pessimistic transactions and optimistic transactions handle data differently, it is more appropriate to consider several points together.

I recommend you check out Tong Mu’s interpretation of transactions:

It’s a bit mind-bending, so be prepared :cowboy_hat_face:

| username: ddhe9527 | Original post link

The concept of current read is under the pessimistic transaction mode. In the optimistic transaction mode, all reads are snapshot reads, and lock acquisition and conflict checks are resolved during the prewrite phase.

| username: Gin | Original post link

Except for select for update under pessimistic locking, all other select statements are snapshot reads and do not lock.

| username: Raymond | Original post link

Ah, TiDB does not support current reads in optimistic transaction mode. In other words, in optimistic mode, reads only exist in the form of snapshot reads? So, current reads like “select xxx for update” are not supported?

| username: ddhe9527 | Original post link

Optimistic transactions support select for update, but it is still a snapshot read, so the result is the same as select. It just goes through the lock and unlock process during COMMIT.

| username: Raymond | Original post link

Hello, teacher.
Actually, I don’t quite understand. So, may I ask, if in optimistic transaction mode, an update statement is executed to update data, it must first read this data into the TiDB server’s mem buffer. When reading this data, is it also read in a snapshot read manner (by comparing with the transaction’s start.tso)? Wouldn’t the data read this way not be the latest? Could there be any issues?

For example, when MySQL updates data, it directly reads the latest version of the data through the current read and updates the data on this latest version.

| username: ddhe9527 | Original post link

There is no issue. In the prewrite phase, there is a step for version checking, which checks whether the commit_ts of the write column is later than its own start_ts. If it is, it indicates a version conflict (another transaction has already been committed), and the entire transaction is directly canceled. Therefore, although optimistic transactions use snapshot reads, their successful commitment is based on the premise that no other transactions have been committed before them. This also ensures that even snapshot reads are of the latest data. Additionally, this cannot be compared with MySQL, as MySQL does not have optimistic transactions.

| username: forever | Original post link

Then this should not be reading data, just checking if there is a start_ts earlier than its own.

| username: Raymond | Original post link

It can actually be understood that in the optimistic transaction model, when updating data, although data is read in a snapshot read manner, it is actually possible to read the latest data.

| username: ddhe9527 | Original post link

You can understand it this way, otherwise it will report a write conflict.

| username: system | Original post link

This topic will be automatically closed 60 days after the last reply. No new replies are allowed.