pingcap / pingcap/tidb

Additional blocking is needed to realize serializability in TiDB's pessimistic isolation levels

Open
#63,625 3 comments 0 reactions 0 assignees View on GitHub
contribution first-time-contributor type/feature-request
Dominant language
Go
Stars
40.5k
Forks
6.2k
PR merge metrics
PR metrics pending

Description

## Feature Request

I'd like a locking read to be blocked by a concurrent insertion in your Read-Committed and Repeatable-Read isolation levels, so that I can mount a serializability implementation on top of them at second tier. For example, consider creating a table t with two columns: id, value. And we insert two rows (1, 1) and (3, 3) into it. Then we execute statements in two transactions T1 and T2 in the following specific order in two prompts under either isolation level:

T1 T2

start transaction;

insert into t values (2,2);

start transaction;

select * from t where id>0 and id<4 for update;

I expect T1's locking read would block for the write lock T2 is holding. But instead in TiDB, T1 doesn't hang.

Notice it doesn't require gap lock to realize this feature. In NDB Cluster, this locking read acquires a short write lock(released after execution of the statement) for each scanned row, and only escalates it to be a long write locks if it is a match(in this case, long locks will be held on (1, 1) and (3, 3)). But a short write lock on (2, 2) requested by T1 will block for T2's and give us the desired behavior. This is a key feature I've used to realize serializability in NDB Cluster's Read-Committed isolation level at second tier.

Right now, I can only mount a serializability implementation to TiDB's Snapshot Isolation at second tier. This missing feature is the only missing piece of the puzzle that would enable me to achieve the same goal at the other two isolation levels for TiDB. Please refer to the section for TiDB in Appendix D in my work for more information: https://github.com/creamyfish/conflict_serializability

Sincerely
Alex Ou

Contributor guide

Open the contributing guide

Research direction

No implementation files or tests are identified in the issue. Start by reproducing the two-transaction sequence under Read Committed and Repeatable Read, then trace the locking-read behavior; done means the locking read blocks on the concurrent insertion as described, with coverage for both isolation levels.

Written by the indexing model from the issue text.

Assessment

Tech stack
sql
Domain
databases, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.