[
https://issues.apache.org/jira/browse/IGNITE-22286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-22286:
---------------------------------------
Description:
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.
was:
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 on step 2 tx3 would retry too on step 4.
> 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)
