From e460a665304bf5e3f738368586efda8a201b1069 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 bf073ffb8ec70eeef98c3906380ec0be8800f54a 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 d297a5fc125b346988c2ec68fe2d7e7ff3386f36 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 a2894ab60979e7dc80d945aa482f6270ff23e900 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