[
https://issues.apache.org/jira/browse/IGNITE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-22130:
---------------------------------------
Description:
Recently (IGNITE-21540) retries was introduced for transactions, both explicit
and implicit.
But the current implementation has flaws:
# In embedded mode retries cause recursion (because the future is completed on
the same thread), which can lead to stack overflow.
# Retries are executed without delay in a loop, which might not give enough
time for conflicting lock release, making retries almost useless.
# Read operations are not retried but need to.
To fix 1 and 2 I suggest to submit a response for retryable operation (if retry
is required) to another thread to avoid recursion and introduce retry delay for
retriable operations, preferrably with exponential back-off.
Fix for 3 is obvious.
was:
Recently (IGNITE-21540) retries was introduced for transactions, both explicit
and implicit.
But the current implementation has flaws:
# In embedded mode retries cause recursion (because the future is completed on
the same thread), which can lead to stack overflow.
# Retries executed without delay in a loop, which might not give enough time
for conflicting lock release, making retries almost useless.
# Read operations are not retried but need to.
To fix 1 and 2 I suggest to submit a response for retryable operation (if retry
is required) to another thread to avoid recursion and introduce retry delay for
retriable operations, preferrably with exponential back-off.
Fix for 3 is obvious.
> Fix retry logic for transactions
> --------------------------------
>
> Key: IGNITE-22130
> URL: https://issues.apache.org/jira/browse/IGNITE-22130
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexey Scherbakov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> Recently (IGNITE-21540) retries was introduced for transactions, both
> explicit and implicit.
> But the current implementation has flaws:
> # In embedded mode retries cause recursion (because the future is completed
> on the same thread), which can lead to stack overflow.
> # Retries are executed without delay in a loop, which might not give enough
> time for conflicting lock release, making retries almost useless.
> # Read operations are not retried but need to.
> To fix 1 and 2 I suggest to submit a response for retryable operation (if
> retry is required) to another thread to avoid recursion and introduce retry
> delay for retriable operations, preferrably with exponential back-off.
> Fix for 3 is obvious.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
