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 Goncharuk (JIRA)" <ji...@apache.org> on 2019/06/07 08:59:00 UTC
[jira] [Commented] (IGNITE-5714) Implementation of suspend/resume
for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16858409#comment-16858409 ]
Alexey Goncharuk commented on IGNITE-5714:
------------------------------------------
[~alex_pl] agree with the approach generally.
Why do we need to differentiate single implicit transaction in the `GridCacheMvccCandidate#isHeldByTx()`? The name of the method is misleading.
Can we define the semantics of the candidate that if it is held by a transaction, it will be held by an XID; otherwise, if it's an implicit lock, it is held by the thread ID (just wondering if it's possible).
> 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: 10m
> 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
(v7.6.3#76005)