You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Denis Chudov (Jira)" <ji...@apache.org> on 2024/09/02 16:17:00 UTC
[jira] [Commented] (IGNITE-22286) Remove waitTimeout in deadlock prevention policy
[ https://issues.apache.org/jira/browse/IGNITE-22286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878622#comment-17878622 ]
Denis Chudov commented on IGNITE-22286:
---------------------------------------
Benchmark results:
{code:java}
+------------------------------------+-------------+------------------+-------------------------+
| Configuration | total txns | rolled back txns | average upsert duration |
+------------------------------------+-------------+------------------+-------------------------+
| Timeout wait, 1 node, 2 cores| 1611 | 166 | 7.583306 |
| Timeout wait, 3 nodes, 2 cores| 1705 | 120 | 17.575059 |
| Timeout wait, 1 node, 8 cores| 3445 | 394 | 3.911635 |
| Timeout wait, 3 nodes, 8 cores| 3055 | 371 | 4.813581 |
| WaitDie + retries, 1 node, 2 cores| 8160 | 169 | 12.158225 |
| WaitDie + retries, 3 nodes, 2 cores| 3853 | 213 | 10.584286 |
| WaitDie + retries, 1 node, 8 cores| 22797 | 2477 | 8.767905 |
| WaitDie + retries, 3 nodes, 8 cores| 13092 | 1285 | 12.519806 |
+------------------------------------+-------------+------------------+-------------------------+ {code}
> Remove waitTimeout in deadlock prevention policy
> ------------------------------------------------
>
> Key: IGNITE-22286
> URL: https://issues.apache.org/jira/browse/IGNITE-22286
> Project: Ignite
> Issue Type: Improvement
> Affects Versions: 3.0.0-beta1
> Reporter: Alexey Scherbakov
> Assignee: Denis Chudov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> After IGNITE-21540 and IGNITE-20127 we now have proper retries on client side.
> This means we no longer need org.apache.ignite.internal.tx.DeadlockPreventionPolicy#waitTimeout as a part of deadock prevention policy.
> Moreover, client side retries has benefit in the following scenario (having in mind WAIT_DIE prevention):
> # tx1 takes lock at timestamp 10
> # tx2 tries to take lock at timestamp 20 and goes for retry (without holding lock)
> # tx1 lock is released
> # tx3 takes lock at timestamp 30
> # tx3 lock is released
> # tx2 attemps to lock after retry and succeeds
> Without retry (without holding locks) on step 2 tx3 would retry too on step 4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)