[
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:
-------------------------------------------
[~gvvinblade],
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
(v7.6.14#76016)
