From 23d46b20053c1496bc2628b7aa6e30e39f9d0278 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Thu, 16 Oct 2025 03:41:35 +0000 Subject: [PATCH 1/4] Initial plan From 0bcd25a4c273fcaec5640b18d5d53caa943f3665 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Thu, 16 Oct 2025 03:45:50 +0000 Subject: [PATCH 2/4] Update optimistic-transaction.md to reflect v3.0.8 default change Co-authored-by: lilin90 <30922556+lilin90@users.noreply.github.com> --- optimistic-transaction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/optimistic-transaction.md b/optimistic-transaction.md index f7e4b1fe558c1..45934be8b38d9 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -69,7 +69,7 @@ However, TiDB transactions also have the following disadvantages: > > Starting from v8.0.0, the [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry) system variable is deprecated, and TiDB no longer supports automatic retries of optimistic transactions. It is recommended to use the [Pessimistic transaction mode](/pessimistic-transaction.md). If you encounter optimistic transaction conflicts, you can capture the error and retry transactions in your application. -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. +In the optimistic transaction model, transactions might fail to be committed because of write–write conflict in heavy contention scenarios. Before v3.0.8, TiDB used 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 b6f00e4a83717883053a307135a300667b2cfd1b Mon Sep 17 00:00:00 2001 From: houfaxin Date: Thu, 16 Oct 2025 14:40:52 +0800 Subject: [PATCH 3/4] Update optimistic-transaction.md --- optimistic-transaction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 45934be8b38d9..12c6c32105290 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -6,7 +6,7 @@ aliases: ['/docs/dev/optimistic-transaction/','/docs/dev/reference/transactions/ # TiDB Optimistic Transaction Model -With optimistic transactions, conflicting changes are detected as part of a transaction commit. This helps improve the performance when concurrent transactions are infrequently modifying the same rows, because the process of acquiring row locks can be skipped. In the case that concurrent transactions frequently modify the same rows (a conflict), optimistic transactions may perform worse than [Pessimistic Transactions](/pessimistic-transaction.md). +With optimistic transactions, conflicting changes are detected as part of a transaction commit. This helps improve the performance when concurrent transactions are infrequently modifying the same rows, because the process of acquiring row locks can be skipped. In the case that concurrent transactions frequently modify the same rows (a conflict), optimistic transactions might perform worse than [pessimistic transactions](/pessimistic-transaction.md). Before enabling optimistic transactions, make sure that your application correctly handles that a `COMMIT` statement could return errors. If you are unsure of how your application handles this, it is recommended to instead use Pessimistic Transactions. @@ -69,7 +69,7 @@ However, TiDB transactions also have the following disadvantages: > > Starting from v8.0.0, the [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry) system variable is deprecated, and TiDB no longer supports automatic retries of optimistic transactions. It is recommended to use the [Pessimistic transaction mode](/pessimistic-transaction.md). If you encounter optimistic transaction conflicts, you can capture the error and retry transactions in your application. -In the optimistic transaction model, transactions might fail to be committed because of write–write conflict in heavy contention scenarios. Before v3.0.8, TiDB used 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. +In the optimistic transaction model, transactions might fail to be committed because of write–write conflict in heavy contention scenarios. TiDB uses the [pessimistic transaction mode](/pessimistic-transaction.md) by default, the same as MySQL. This means that TiDB and MySQL add 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 446e0aa30a34096da5a9cc2ada1f579460b838d3 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Thu, 16 Oct 2025 15:26:55 +0800 Subject: [PATCH 4/4] Update optimistic-transaction.md Co-authored-by: Lilian Lee --- optimistic-transaction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 12c6c32105290..78f3efd1de1f3 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -69,7 +69,7 @@ However, TiDB transactions also have the following disadvantages: > > Starting from v8.0.0, the [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry) system variable is deprecated, and TiDB no longer supports automatic retries of optimistic transactions. It is recommended to use the [Pessimistic transaction mode](/pessimistic-transaction.md). If you encounter optimistic transaction conflicts, you can capture the error and retry transactions in your application. -In the optimistic transaction model, transactions might fail to be committed because of write–write conflict in heavy contention scenarios. TiDB uses the [pessimistic transaction mode](/pessimistic-transaction.md) by default, the same as MySQL. This means that TiDB and MySQL add 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. +In the optimistic transaction model, transactions might fail to be committed because of write–write conflict in heavy contention scenarios. Starting from v3.0.8, TiDB uses the [pessimistic transaction mode](/pessimistic-transaction.md) by default, the same as MySQL. This means that TiDB and MySQL add 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