From 2a2248977ee850b71e1446cf1633d6c158fa6526 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 2403dbc608fa5..8f46108251179 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -65,7 +65,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 3b2ec9ca8f8d3..5da2af2165730 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -50,9 +50,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 bfb8c935c84e892aeff4858a7f3faad243dc2d97 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 5da2af2165730..6b18f9ce599af 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -50,7 +50,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 6fc863f1c4a1bc984348cf68e03104ada4c27fa6 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 8f46108251179..c1ffae47f36ba 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -65,7 +65,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 a20688eca93484b9492451744b21b9b48e01c95e 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 6b18f9ce599af..f6dc9540010ae 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -50,7 +50,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