From 0b6caad55a0e33222a1d1524957eade3396916c2 Mon Sep 17 00:00:00 2001 From: you06 Date: Fri, 13 Aug 2021 12:21:24 +0800 Subject: [PATCH 1/4] update transaction doc Signed-off-by: you06 --- 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..acf08331323fa 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 SQL execution, 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..ed7cb6b8189bd 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 transaction mechanism might fail, leading to a final failure of the transaction, while in TiDB's pessimistic transaction mechanism and MySQL, the updating transaction can be successful. ## Read Committed isolation level From df77cbad259854a0ed68cd81130b5b9c7a335db4 Mon Sep 17 00:00:00 2001 From: you06 Date: Fri, 13 Aug 2021 12:28:35 +0800 Subject: [PATCH 2/4] update Signed-off-by: you06 --- transaction-isolation-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index ed7cb6b8189bd..5a5bec0d3a3da 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -49,7 +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 optimistic transaction is rolled back and retried. Transaction Retries in TiDB's optimistic transaction mechanism might fail, leading to a final failure of the transaction, while in TiDB's pessimistic transaction mechanism and MySQL, the updating transaction can be successful. +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 From ca0ceab42d8a75c21c33f87cb3f461872ae14c9e Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Wed, 8 Sep 2021 16:42:20 +0800 Subject: [PATCH 3/4] Update optimistic-transaction.md --- optimistic-transaction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/optimistic-transaction.md b/optimistic-transaction.md index acf08331323fa..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 current 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 From 0422df374e50f76a3a1222cb4e0c444b9daa0ed8 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Wed, 8 Sep 2021 16:42:28 +0800 Subject: [PATCH 4/4] Update transaction-isolation-levels.md --- transaction-isolation-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index 5a5bec0d3a3da..8f01218665ea2 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -49,7 +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 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. +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