[
https://issues.apache.org/jira/browse/IGNITE-28192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-28192:
--------------------------------------
Assignee: (was: Ivan Bessonov)
> Phantom reads in RW scans
> -------------------------
>
> Key: IGNITE-28192
> URL: https://issues.apache.org/jira/browse/IGNITE-28192
> Project: Ignite
> Issue Type: Bug
> Reporter: Ivan Bessonov
> Priority: Major
> Labels: ignite-3
> Attachments: IGNITE-28192.patch
>
>
> {{ItTableScanTest#testPhantomReads}} is flaky, with a rate of about 1%
> locally. I'm providing no TC link because I didn't check its state. Here I
> will describe how it happens:
> * Initially we have following rows in an index: {{10, 40}}.
> * Read-Write scan is started. It acquires a lock to {{10}}.
> * We do a {{"PUT 30"}} operation, let's call it {{TX_A}}.
> ** It successfully acquires a "next" side of a gap lock first. it's
> currently a {{40}}.
> ** It successfully acquires a "current" side of a gap lock, which is {{30}}.
> The gap lock is {{[40, 30]}}
> ** There's no data insertion yet.
> * Another thread does a {{"PUT 20"}} operation, let's call it {{TX_B}}.
> ** It reads the "next" side of a gap lock candidate from the index. It's
> {{40}}.
> * {{TX_A}} finishes.
> ** {{30}} is inserted into the index.
> ** Gap lock {{[40, 30]}} is released.
> * Scan acquires a lock {{30}}, which gives a gap lock {{[10, 30]}}.
> * {{TX_B}} acquires a lock {{40}} that it previously read.
> ** Then it acquires a lock for its own key {{20}}, forming a {{[40, 20]}}
> gap lock. _It does NOT re-read "next" key and doesn't reacquire a proper
> "next" side_ (which is {{30}}, not {{40}}).
> ** Then {{TX_B}} inserts {{20}} into the index and finishes, releasing a
> {{[40, 20]}} gap lock.
> * Scan finishes with acquiring a {{[30, 40]}} gap lock. Data that it has read
> is {{10, 30, 40}}. And {{20}} is inserted into index concurrently.
> * Second scan of the same index will return {{10, 20, 30, 40}}, giving us a
> phantom read of {{20}}.
> UPDATE: I don't think that {{if (!rowIdMatches(peekedRow,
> peekedRowAfterLock))}} is correct either, we may need to compare the payload.
> Let's check the design document and use common sense here.
> UPDATE 2: Information here is not 100% accurate. Insertions do release
> short-term locks before commit, this is not reflected in the scenario, but it
> should not change the outcome.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
