[
https://issues.apache.org/jira/browse/IGNITE-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-5613:
-------------------------------------
Description:
Consider the following update scenario:
{code}
Thread 1:
Transaction tx = txStart() {
get(key); // Acquires lock;
seq.incrementAndGet();
}
Thread 2:
seq.incrementAndGet();
{code}
Let's now assume that:
* Sequence is exhausted and needs a non-local update
* Thread 1 acquired lock on topology version N
* Topology version changes
* Thread 2 now calls incrementAndGet(), acquires lock and starts transaction
which waits for topology version N+1 to become available
* Thread 1 attemts to incrementAndGet().
Since the lock is already held, it waits for the concurrent update to complete
was:
Consider the following update scenario:
{code}
Thread 1:
Transaction tx = txStart() {
get(key); // Acquires lock;
seq.incrementAndGet();
}
Thread 2:
seq.incrementAndGet();
{code}
Let's now assume that:
* Sequence is exhausted and needs a non-local update
* Thread 1 acquired lock on topology version N
* Topology version changes
* Thread 2 now calls incrementAndGet(), updates the sequence local guard and
starts transaction which waits for topology version N+1 to become available
* Thread 1 attemts to incrementAndGet().
Since guard is already changed, it waits for the concurrent update to complete
> AtomicSequence usage inside transactions may cause deadlock
> -----------------------------------------------------------
>
> Key: IGNITE-5613
> URL: https://issues.apache.org/jira/browse/IGNITE-5613
> Project: Ignite
> Issue Type: Bug
> Components: cache
> Affects Versions: 1.5.0.final
> Reporter: Alexey Goncharuk
> Labels: important
> Fix For: 2.1
>
>
> Consider the following update scenario:
> {code}
> Thread 1:
> Transaction tx = txStart() {
> get(key); // Acquires lock;
> seq.incrementAndGet();
> }
> Thread 2:
> seq.incrementAndGet();
> {code}
> Let's now assume that:
> * Sequence is exhausted and needs a non-local update
> * Thread 1 acquired lock on topology version N
> * Topology version changes
> * Thread 2 now calls incrementAndGet(), acquires lock and starts transaction
> which waits for topology version N+1 to become available
> * Thread 1 attemts to incrementAndGet().
> Since the lock is already held, it waits for the concurrent update to complete
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
