Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
3.0
-
Docs Required, Release Notes Required
Description
Steps to reproduce:
1. Start AI3 cluster with 3 or more nodes
2. Create a simple table with an index:
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')
3. Run 2 parallel transactions that try to insert values with the same value for the indexed column (not PK!). For example:
-- First transaction INSERT INTO indexed_kids (id, name) VALUES (9, 'Kolobok') -- Second transaction INSERT INTO indexed_kids (id, name) VALUES (12, 'Kolobok')
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]
Attachments
Issue Links
- relates to
-
IGNITE-23065 Sql. Make retries of transactional operations
-
- Open
-
- links to
