[
https://issues.apache.org/jira/browse/IGNITE-23034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-23034:
----------------------------------
Description:
{*}Steps to reproduce{*}:
1. Start AI3 cluster with *3 or more* nodes
2. Create a simple table with an index:
{code:sql}
CREATE TABLE indexed_kids(id INTEGER, name VARCHAR(100), primary key (id))
CREATE INDEX indexed_kids_index on indexed_kids using SORTED (name)
INSERT INTO indexed_kids (id, name) VALUES (1, 'Europe')
{code}
3. Run 2 parallel transactions that try to insert values with the same value
for the *indexed column* (not PK!). For example:
{code:sql}
-- First transaction
INSERT INTO indexed_kids (id, name) VALUES (9, 'Kolobok')
-- Second transaction
INSERT INTO indexed_kids (id, name) VALUES (12, 'Kolobok')
{code}
{*}Expected behavior{*}:
We expect both transactions to pass, in general.
{*}Actual behavior{*}:
Looks like it depends on 3 metrics: cluster size, amount of table partitions
and amount of table replicas. In some cases, one transaction may fail with
*SQLException* ("Failed to acquire a lock due to a possible deadlock")
For example, in a cluster of 1 or 2 nodes, the second transaction always fail.
In a cluster of 3 nodes, it may pass on default zone settings, but fails again
when we increase amount of table partitions and/or replicas.
*Implementation notes*
We should fix the behaviour according to Transactional IEP (section Sorted
non-unique index) [1] and the paper describing locking model [2]
[1]
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Non-uniqueindex]
[2] https://www.vldb.org/conf/1990/P392.PDF
was:
{*}Steps to reproduce{*}:
1. Start AI3 cluster with *3 or more* nodes
2. Create a simple table with an index:
{code:sql}
CREATE TABLE indexed_kids(id INTEGER, name VARCHAR(100), primary key (id))
CREATE INDEX indexed_kids_index on indexed_kids using SORTED (name)
INSERT INTO indexed_kids (id, name) VALUES (1, 'Europe')
{code}
3. Run 2 parallel transactions that try to insert values with the same value
for the *indexed column* (not PK!). For example:
{code:sql}
-- First transaction
INSERT INTO indexed_kids (id, name) VALUES (9, 'Kolobok')
-- Second transaction
INSERT INTO indexed_kids (id, name) VALUES (12, 'Kolobok')
{code}
{*}Expected behavior{*}:
We expect both transactions to pass, in general.
{*}Actual behavior{*}:
Looks like it depends on 3 metrics: cluster size, amount of table partitions
and amount of table replicas. In some cases, one transaction may fail with
*SQLException* ("Failed to acquire a lock due to a possible deadlock")
For example, in a cluster of 1 or 2 nodes, the second transaction always fail.
In a cluster of 3 nodes, it may pass on default zone settings, but fails again
when we increase amount of table partitions and/or replicas.
> Issuses with concurrent inserts that depend on cluster size and zone settings
> -----------------------------------------------------------------------------
>
> Key: IGNITE-23034
> URL: https://issues.apache.org/jira/browse/IGNITE-23034
> Project: Ignite
> Issue Type: Bug
> Components: sql
> Affects Versions: 3.0
> Reporter: Andrey Khitrin
> Priority: Major
> Labels: ignite-3, index, transaction
>
> {*}Steps to reproduce{*}:
> 1. Start AI3 cluster with *3 or more* nodes
> 2. Create a simple table with an index:
> {code:sql}
> CREATE TABLE indexed_kids(id INTEGER, name VARCHAR(100), primary key (id))
> CREATE INDEX indexed_kids_index on indexed_kids using SORTED (name)
> INSERT INTO indexed_kids (id, name) VALUES (1, 'Europe')
> {code}
> 3. Run 2 parallel transactions that try to insert values with the same value
> for the *indexed column* (not PK!). For example:
> {code:sql}
> -- First transaction
> INSERT INTO indexed_kids (id, name) VALUES (9, 'Kolobok')
> -- Second transaction
> INSERT INTO indexed_kids (id, name) VALUES (12, 'Kolobok')
> {code}
> {*}Expected behavior{*}:
> We expect both transactions to pass, in general.
> {*}Actual behavior{*}:
> Looks like it depends on 3 metrics: cluster size, amount of table partitions
> and amount of table replicas. In some cases, one transaction may fail with
> *SQLException* ("Failed to acquire a lock due to a possible deadlock")
> For example, in a cluster of 1 or 2 nodes, the second transaction always
> fail. In a cluster of 3 nodes, it may pass on default zone settings, but
> fails again when we increase amount of table partitions and/or replicas.
> *Implementation notes*
> We should fix the behaviour according to Transactional IEP (section Sorted
> non-unique index) [1] and the paper describing locking model [2]
> [1]
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Non-uniqueindex]
> [2] https://www.vldb.org/conf/1990/P392.PDF
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
