ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Plekhanov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
Date Wed, 07 Aug 2019 09:48:00 GMT

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

Aleksey Plekhanov commented on IGNITE-5714:


As far as I understand {{TxFinishSync}} was introduced to avoid problems with locks intersection
(by {{threadId}} in {{GridCacheMvccCandidate}}) between two transactions started by the same
thread. This problem affects only pessimistic transactions. 
After this patch explicit pessimistic transactions will use locking by {{GridCacheVersion}} (not
by {{threadId}} as before). There is no intersection by {{threadId}} anymore and {{TxFinishSync}} is
not needed. 
Implicit pessimistic transactions can only be created if MVCC is enabled. But when MVCC is
enabled another locking mechanism is used (instead of {{GridCacheMvccCandidate}} a {{DataRow}} is
used to store locks information and there is no intersection by {{threadId}}). For these
transaction types {{TxFinishSync}} is not needed too.
So, {{TxFinishSync}} can be safely removed.

If we will use thread-local {{GridCacheVersion}} for explicit locks we also need to use the
same {{GridCacheVersion}} for implicit transactions. This brings additional complexity to
the code and new risks. I propose to keep {{threadId}} as holder for explicit lock/implicit
tx for now. This doesn't block anything and can be fixed by another ticket (there is already
such [ticket|https://issues.apache.org/jira/browse/IGNITE-8389] created).

I've removed {{TxFinishSync}} and prepared the new patch, please have a look.

> 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: Aleksey Plekhanov
>            Priority: Major
>              Labels: iep-34
>          Time Spent: 4.5h
>  Remaining Estimate: 0h
> 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

View raw message