ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Kuznetsov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
Date Fri, 20 Apr 2018 14:25:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445793#comment-16445793
] 

Alexey Kuznetsov edited comment on IGNITE-5714 at 4/20/18 2:24 PM:
-------------------------------------------------------------------

[~agoncharuk] There are some scenarios, which need to be handled with thread id. For instance:
1)look at the code:

{code:java}
        cache.lock(key1).lock();

        cache.put(key1, 1);// implicit transaction is started here
{code}

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 (Author: alexey kuznetsov):
[~agoncharuk] There are some scenarios, which need to be handled with thread id. For instance:
1)look at the code:

{code:java}
        cache.lock(key1).lock();

        cache.put(key1, 1);
{code}

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.



> Implementation of suspend/resume for pessimistic transactions
> -------------------------------------------------------------
>
>                 Key: IGNITE-5714
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5714
>             Project: Ignite
>          Issue Type: Sub-task
>          Components: general
>            Reporter: Alexey Kuznetsov
>            Assignee: Alexey Kuznetsov
>            Priority: Major
>             Fix For: 2.6
>
>
> Support transaction suspend()\resume() operations for pessimistic transactions. Resume
can be called in another thread.
>    _+But there is a problem+_: Imagine, we started pessimistic transaction in thread
T1 and then perform put operation, which leads to sending GridDistributedLockRequest to another
node. Lock request contains thread id of the transaction. Then we call suspend, resume in
another thread and we also must send messages to other nodes to change thread id. 
> It seems complicated task.It’s better to get rid of sending thread id to the nodes.
> We can use transaction xid on other nodes instead of thread id. Xid is sent to nodes
in GridDistributedLockRequest#nearXidVer
>    _+Proposed solution+_ : On remote nodes instead of thread id of near transaction GridDistributedLockRequest#threadId
use its xid GridDistributedLockRequest#nearXidVer.
> Remove usages of near transaction's thread id on remote nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message