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

Vyacheslav Koptilin reassigned IGNITE-23034:
--------------------------------------------

    Assignee:  Kirill Sizov

> 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
>            Assignee:  Kirill Sizov
>            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)

Reply via email to