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/05/24 16:12: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=17849340#comment-17849340 ] 

Denis Chudov commented on IGNITE-22286:
---------------------------------------

The profit of the client-side timeout is not clear in comparison to server-side timeout. We should do some benchmarks first.

I created IGNITE-22329 to check that another (timeout) deadlock prevention policy would be operable.

> 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
>            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)