You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Igor Belyakov (Jira)" <ji...@apache.org> on 2022/05/13 09:33:00 UTC
[jira] [Updated] (IGNITE-16978) SQL update fails with "modified concurrently" error for REPLICATED cache with TRANSACTIONAL atomicity mode
[ https://issues.apache.org/jira/browse/IGNITE-16978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Belyakov updated IGNITE-16978:
-----------------------------------
Description:
In case SQL update query executed for the same key multiple times using JDBC or Java thin client, sometimes it leads to:
{code:java}
Failed to update some keys because they had been modified concurrently [keys=[1]]{code}
There is no concurrent updates execution, all updates are executed one by one in the same thread.
The issue is reproducible only in the case of {{REPLICATED}} cache with {{TRANSACTIONAL}} atomicity mode and the client should be connected to the server node where backup entry is stored. The issue can be easily reproduced if any client node joins/leaves the cluster during the query execution, but also the issue happens without any additional actions
In case {{REPLICATED}} cache is replaced by {{PARTITIONED}} with {{{}BACKUPS=1{}}}, using a cluster with 2 server nodes, the issue is not reproducible anymore. The same happens after changing atomicity mode from {{TRANSACTIONAL}} to {{{}ATOMIC{}}}.
Reproducer attached.
was:
In case SQL update query executed for the same key multiple times using JDBC or Java thin client, sometimes it leads to:
Failed to update some keys because they had been modified concurrently [keys=[1]]
There is no concurrent updates execution, all updates are executed one by one in the same thread.
The issue is reproducible only in the case of {{REPLICATED}} cache with {{TRANSACTIONAL}} atomicity mode and the client should be connected to the server node where backup entry is stored.
The issue can be easily reproduced if any client node joins/leaves the cluster during the query execution, but also the issue happens without any additional actions.
Also, in case {{REPLICATED}} cache is replaced by {{PARTITIONED}} with {{{}BACKUPS=1{}}}, using a cluster with 2 server nodes, the issue is not reproducible anymore. The same happens after changing atomicity mode from {{TRANSACTIONAL}} to {{{}ATOMIC{}}}.
Reproducer attached.
> SQL update fails with "modified concurrently" error for REPLICATED cache with TRANSACTIONAL atomicity mode
> ----------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-16978
> URL: https://issues.apache.org/jira/browse/IGNITE-16978
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 2.12
> Reporter: Igor Belyakov
> Priority: Major
>
> In case SQL update query executed for the same key multiple times using JDBC or Java thin client, sometimes it leads to:
> {code:java}
> Failed to update some keys because they had been modified concurrently [keys=[1]]{code}
> There is no concurrent updates execution, all updates are executed one by one in the same thread.
> The issue is reproducible only in the case of {{REPLICATED}} cache with {{TRANSACTIONAL}} atomicity mode and the client should be connected to the server node where backup entry is stored. The issue can be easily reproduced if any client node joins/leaves the cluster during the query execution, but also the issue happens without any additional actions
> In case {{REPLICATED}} cache is replaced by {{PARTITIONED}} with {{{}BACKUPS=1{}}}, using a cluster with 2 server nodes, the issue is not reproducible anymore. The same happens after changing atomicity mode from {{TRANSACTIONAL}} to {{{}ATOMIC{}}}.
> Reproducer attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)