[
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.
As to Atomic caches, there is even no chance to lock entry before the check,
so, the inconsistency window is wider than in the tx case.
This problem does not allow to use ReadRepair with concurrent modifications,
since repair may happen because of an inconsistent read (while another
operation is in progress), not because of real inconsistency.
A possible solution is to implement fake updates, which will guarantee that the
previous update is fully finished -> consistent read.
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 (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".
> 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.
> As to Atomic caches, there is even no chance to lock entry before the check,
> so, the inconsistency window is wider than in the tx case.
> This problem does not allow to use ReadRepair with concurrent modifications,
> since repair may happen because of an inconsistent read (while another
> operation is in progress), not because of real inconsistency.
> A possible solution is to implement fake updates, which will guarantee that
> the previous update is fully finished -> consistent read.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
