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)