[
https://issues.apache.org/jira/browse/IGNITE-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-8389:
-------------------------------------
Description:
After implemeting support for suspend\resume operations for pessimistic txs :
[ticket|https://issues.apache.org/jira/browse/IGNITE-5714]
thread id still exists in MVCC candidate, but its unused on remote nodes(xid is
used instead) and it leads to hard-to-catch bugs. Note that we still need
thread ID on local nodes.
In this ticket we should remove completely thread id from MVCC candidate and
use another mechanism instead.
Currently, MVCC candidate make use of threadID in the following scenarios:
1)look at the code:
cache.lock(key1).lock();
cache.put(key1, 1);// implicit transaction is started here
Implicit transaction will check whether key is locked explicitly by current
thread(thread ID is used here) , see GridNearTxLocal#updateExplicitVersion.
This allows transaction not to gain lock on tx entry, but reuse cache lock.
2) Thread ID is used by explicit transaction to check whether key is locally
locked(and throw exception) , see GridNearTxLocal#enlistWriteEntry.
3) Also, thread ID is used to mark candidate as reentry. etc.
was:
After implemeting support for suspend\resume operations for pessimistic txs :
[ticket|https://issues.apache.org/jira/browse/IGNITE-5714]
thread id still exists in MVCC candidate, but its unused on remote nodes(xid is
used instead) and it leads to hard-to-catch bugs.
In this ticket we should remove thread id from MVCC candidate and make use of
another mechanism instead.
Currently, MVCC candidate make use of threadID in the following scenarios:
1)look at the code:
cache.lock(key1).lock();
cache.put(key1, 1);// implicit transaction is started here
Implicit transaction will check whether key is locked explicitly by current
thread(thread ID is used here) , see GridNearTxLocal#updateExplicitVersion.
This allows transaction not to gain lock on tx entry, but reuse cache lock.
2) Thread ID is used by explicit transaction to check whether key is locally
locked(and throw exception) , see GridNearTxLocal#enlistWriteEntry.
3) Also, thread ID is used to mark candidate as reentry. etc.
> Get rid of thread ID in MVCC candidate
> --------------------------------------
>
> Key: IGNITE-8389
> URL: https://issues.apache.org/jira/browse/IGNITE-8389
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexey Kuznetsov
> Assignee: Alexey Kuznetsov
> Priority: Major
> Labels: transactions
>
> After implemeting support for suspend\resume operations for pessimistic txs :
> [ticket|https://issues.apache.org/jira/browse/IGNITE-5714]
> thread id still exists in MVCC candidate, but its unused on remote nodes(xid
> is used instead) and it leads to hard-to-catch bugs. Note that we still need
> thread ID on local nodes.
> In this ticket we should remove completely thread id from MVCC candidate and
> use another mechanism instead.
> Currently, MVCC candidate make use of threadID in the following scenarios:
> 1)look at the code:
> cache.lock(key1).lock();
> cache.put(key1, 1);// implicit transaction is started here
> Implicit transaction will check whether key is locked explicitly by current
> thread(thread ID is used here) , see GridNearTxLocal#updateExplicitVersion.
> This allows transaction not to gain lock on tx entry, but reuse cache lock.
> 2) Thread ID is used by explicit transaction to check whether key is locally
> locked(and throw exception) , see GridNearTxLocal#enlistWriteEntry.
> 3) Also, thread ID is used to mark candidate as reentry. etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
