[
https://issues.apache.org/jira/browse/IGNITE-15316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-15316:
--------------------------------------
Description:
Even at FULL_SYNC mode stale reads are possible from backups after the lock is
obtained by "Read Repair" tx.
This is possible because (at previous tx) entry becomes unlocked (committed) on
primary before tx committed on backups.
This is not a problem for Ignite (since backups keep locks until updated) but
produces false positive "inconsistency state found" events and repairs.
Unlock relocation does not seems to be a proper fix, since it will cause a
performance drop.
So, we should recheck values several times if an inconsistency is found, even
when the lock is already obtained by "Read Repair".
was:
Even at FULL_SYNC mode stale reads are possible from backups after the lock is
obtained by "Read Repair" tx.
This is possible because (at previous tx) entry becomes unlocked on primary
before tx committed on backups.
This is not a critical problem for Ignite in general but produces false
positive "inconsistency state found" events and repairs.
Unlock relocation does not seems to be a proper fix, since it will cause a
performance drop.
So, we should recheck values several times if an inconsistency is found, even
when the lock is already obtained by "Read Repair".
> Read Repair may see inconsistent entry at tx cache when it is consistent but
> updated right before the check
> -----------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-15316
> URL: https://issues.apache.org/jira/browse/IGNITE-15316
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: iep-31
>
> Even at FULL_SYNC mode stale reads are possible from backups after the lock
> is obtained by "Read Repair" tx.
> This is possible because (at previous tx) entry becomes unlocked (committed)
> on primary before tx committed on backups.
> This is not a problem for Ignite (since backups keep locks until updated) but
> produces false positive "inconsistency state found" events and repairs.
> Unlock relocation does not seems to be a proper fix, since it will cause a
> performance drop.
> So, we should recheck values several times if an inconsistency is found, even
> when the lock is already obtained by "Read Repair".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
