Ivan Bessonov created IGNITE-28192:
--------------------------------------
Summary: 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
Assignee: Ivan Bessonov
{{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 right side of a gap lock first. it's currently a
{{40}}.
** It successfully acquires a left 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 right 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 right
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}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
