You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexey Kuznetsov (JIRA)" <ji...@apache.org> on 2018/07/18 11:03:00 UTC
[jira] [Assigned] (IGNITE-8389) Get rid of thread ID in MVCC
candidate
[ https://issues.apache.org/jira/browse/IGNITE-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Kuznetsov reassigned IGNITE-8389:
----------------------------------------
Assignee: (was: Alexey Kuznetsov)
> 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
> 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)