[
https://issues.apache.org/jira/browse/IGNITE-15316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-15316:
--------------------------------------
Summary: Read Repair may see inconsistent entry when it is consistent but
updated right before the check (was: Read Repair may see inconsistent entry at
tx cache when it is consistent but updated right before the check)
> Read Repair may see inconsistent entry 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)
