[jira] [Assigned] (IGNITE-15316) Read Repair may see inconsistent entry when it is consistent but updated right before the check

["Anton Vinogradov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-15316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anton Vinogradov reassigned IGNITE-15316:
-----------------------------------------

    Assignee:     (was: Anton Vinogradov)

> 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
>            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.10#820010)