From 3de58fcfbc6827011f8da23866cafbd192b8c70a Mon Sep 17 00:00:00 2001 From: Ti Chi Robot Date: Wed, 8 Sep 2021 17:24:59 +0800 Subject: [PATCH] update transaction doc (#6158) (#6411) --- optimistic-transaction.md | 2 +- transaction-isolation-levels.md | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 487a73a05aa5f..0a66178d7fb9b 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -64,7 +64,7 @@ However, TiDB transactions also have the following disadvantages: ## Transaction retries -In the optimistic transaction model, transactions might fail to be committed because of write–write conflict in heavy contention scenarios. TiDB uses optimistic concurrency control by default, whereas MySQL applies pessimistic concurrency control. This means that MySQL adds locks during SQL execution, and its Repeatable Read isolation level allows for non-repeatable reads, so commits generally do not encounter exceptions. To lower the difficulty of adapting applications, TiDB provides an internal retry mechanism. +In the optimistic transaction model, transactions might fail to be committed because of write–write conflict in heavy contention scenarios. TiDB uses optimistic concurrency control by default, whereas MySQL applies pessimistic concurrency control. This means that MySQL adds locks during the execution of write-type SQL statements, and its Repeatable Read isolation level allows for current reads, so commits generally do not encounter exceptions. To lower the difficulty of adapting applications, TiDB provides an internal retry mechanism. ### Automatic retry diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index b51b9be268af9..8f01218665ea2 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -49,9 +49,7 @@ The Repeatable Read isolation level in TiDB differs from ANSI Repeatable Read is ### Difference between TiDB and MySQL Repeatable Read -The Repeatable Read isolation level in TiDB differs from that in MySQL. The MySQL Repeatable Read isolation level does not check whether the current version is visible when updating, which means it can continue to update even if the row has been updated after the transaction starts. In contrast, if the row has been updated after the transaction starts, the TiDB transaction is rolled back and retried. Transaction Retries in TiDB might fail, leading to a final failure of the transaction, while in MySQL the updating transaction can be successful. - -The MySQL Repeatable Read isolation level is not the snapshot isolation level. The consistency of MySQL Repeatable Read isolation level is weaker than both the snapshot isolation level and TiDB Repeatable Read isolation level. +The Repeatable Read isolation level in TiDB differs from that in MySQL. The MySQL Repeatable Read isolation level does not check whether the current version is visible when updating, which means it can continue to update even if the row has been updated after the transaction starts. In contrast, if the row has been updated after the transaction starts, the TiDB optimistic transaction is rolled back and retried. Transaction retries in TiDB's optimistic concurrency control might fail, leading to a final failure of the transaction, while in TiDB's pessimistic concurrency control and MySQL, the updating transaction can be successful. ## Read Committed isolation level