[
https://issues.apache.org/jira/browse/IGNITE-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452643#comment-16452643
]
Alexey Kuznetsov commented on IGNITE-8389:
------------------------------------------
[~dpavlov] I was in the middle of filling description )
> 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.
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
