[jira] [Updated] (IGNITE-5613) AtomicSequence usage inside transactions may cause deadlock
[ 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, thread 2 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(), 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 > 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, thread 2 waits for the concurrent update to > complete -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5613) AtomicSequence usage inside transactions may cause deadlock
[ 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)
[jira] [Updated] (IGNITE-5613) AtomicSequence usage inside transactions may cause deadlock
[ https://issues.apache.org/jira/browse/IGNITE-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-5613: - Labels: important (was: ) > 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(), 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 -- This message was sent by Atlassian JIRA (v6.4.14#64029)