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