[jira] [Updated] (IGNITE-28958) Prevent deadlocks in concurrent bulk operations with different key orders

["Vladislav Pyatkov (Jira)" <ji...@apache.org>]

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

Vladislav Pyatkov updated IGNITE-28958:
---------------------------------------
    Description: 
h2.Motivation
Concurrent bulk operations executed in pessimistic transactions may acquire locks for the same set of entries in different orders. This can produce a cyclic lock dependency between transactions and eventually result in a deadlock, transaction timeout, or failure to finish the operation.
The problem can be reproduced with both SQL DML and KeyValue API operations:
# Concurrent UPDATE statements affecting the same rows through a WHERE condition.
# Concurrent IgniteCache.putAll calls whose input maps iterate over the same keys in opposite orders.
# Concurrent IgniteCache.getAll calls whose input sets iterate over the same keys in opposite orders. REPEATABLE_READ isolation is used so that getAll acquires transactional locks.

BulkOperationDeadlockIntegrationTest provides the reproducing scenarios:
- testUpdateWithWhereDoesNotDeadlock
- testPutAllWithOppositeKeyOrderDoesNotDeadlock
- testGetAllWithOppositeKeyOrderDoesNotDeadlock

h2.Definition of done
* concurrent UPDATE operations affecting the same rows do not deadlock;
* concurrent putAll operations with opposite input orders do not deadlock;
* concurrent getAll operations with opposite input orders do not deadlock;
* the corresponding ignored tests can be enabled and pass consistently.


  was:
h2.Motivation
Concurrent bulk operations executed in pessimistic transactions may acquire locks for the same set of entries in different orders. This can produce a cyclic lock dependency between transactions and eventually result in a deadlock, transaction timeout, or failure to finish the operation.
The problem can be reproduced with both SQL DML and KeyValue API operations:
# Concurrent UPDATE statements affecting the same rows through a WHERE condition.
# Concurrent IgniteCache.putAll calls whose input maps iterate over the same keys in opposite orders.
# Concurrent IgniteCache.getAll calls whose input sets iterate over the same keys in opposite orders. REPEATABLE_READ isolation is used so that getAll acquires transactional locks.

BulkOperationDeadlockIntegrationTest provides the reproducing scenarios:
- testUpdateWithWhereDoesNotDeadlock
- testPutAllWithOppositeKeyOrderDoesNotDeadlock
- testGetAllWithOppositeKeyOrderDoesNotDeadlock



> Prevent deadlocks in concurrent bulk operations with different key orders
> -------------------------------------------------------------------------
>
>                 Key: IGNITE-28958
>                 URL: https://issues.apache.org/jira/browse/IGNITE-28958
>             Project: Ignite
>          Issue Type: Bug
>          Components: cache
>            Reporter: Vladislav Pyatkov
>            Priority: Major
>              Labels: calcite, ignite-2, sql
>         Attachments: BulkOperationDeadlockIntegrationTest.java
>
>
> h2.Motivation
> Concurrent bulk operations executed in pessimistic transactions may acquire locks for the same set of entries in different orders. This can produce a cyclic lock dependency between transactions and eventually result in a deadlock, transaction timeout, or failure to finish the operation.
> The problem can be reproduced with both SQL DML and KeyValue API operations:
> # Concurrent UPDATE statements affecting the same rows through a WHERE condition.
> # Concurrent IgniteCache.putAll calls whose input maps iterate over the same keys in opposite orders.
> # Concurrent IgniteCache.getAll calls whose input sets iterate over the same keys in opposite orders. REPEATABLE_READ isolation is used so that getAll acquires transactional locks.
> BulkOperationDeadlockIntegrationTest provides the reproducing scenarios:
> - testUpdateWithWhereDoesNotDeadlock
> - testPutAllWithOppositeKeyOrderDoesNotDeadlock
> - testGetAllWithOppositeKeyOrderDoesNotDeadlock
> h2.Definition of done
> * concurrent UPDATE operations affecting the same rows do not deadlock;
> * concurrent putAll operations with opposite input orders do not deadlock;
> * concurrent getAll operations with opposite input orders do not deadlock;
> * the corresponding ignored tests can be enabled and pass consistently.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)