[
https://issues.apache.org/jira/browse/IGNITE-28192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-28192:
-----------------------------------
Description:
{{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}}.
was:
{{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 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}}.
> 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
> Priority: Major
> Labels: ignite-3
>
> {{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}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
