[ https://issues.apache.org/jira/browse/IGNITE-22286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849340#comment-17849340 ]
Denis Chudov edited comment on IGNITE-22286 at 5/24/24 4:12 PM: ---------------------------------------------------------------- The profit of the client-side timeout is not clear in comparison to server-side timeout. With server-side waiting the locks can be acquired just after the concurrent lock is released, on the client we should wait for a fixed amount of time. We should do some benchmarks first. I created IGNITE-22329 to check that another (timeout) deadlock prevention policy would be operable. was (Author: denis chudov): The profit of the client-side timeout is not clear in comparison to server-side timeout. With server side locks can be acquired just after the concurrent lock is released, on the client we should wait for a fixed amount of time. 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)