[
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)
