[
https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817923#comment-16817923
]
Aleksey Plekhanov edited comment on IGNITE-5714 at 4/24/19 8:30 AM:
--------------------------------------------------------------------
[~agoncharuk], as already described by [~Alexey Kuznetsov] we can't remove
thread ID from MVCC candidate because it's needed for explicit locks
(IgniteCache#lock, IgniteCache#lockAll) when an explicit transaction is not
started. In this case, the lock is held by a thread, not by a transaction.
But I think we can get rid of thread id usage in MVCC candidate for all cases
when the lock is held by a transaction. And more carefully split the logic of
lock checking for locks held by threads and by transactions. In this case,
there is no thread id update needed when thread for the transaction is switched.
What do you think about such solution?
was (Author: alex_pl):
[~agoncharuk], as already described by [~Alexey Kuznetsov] we can't remove
thread ID from MVCC candidate because it's needed for explicit locks
(IgniteCache#lock, IgniteCache#lockAll) when an explicit transaction is not
started. In this case, the lock is held by a thread, not by a transaction.
But I think we can get rid of thread id usage in MVCC candidate for all cases
when the lock is held by a transaction. And more carefully split the logic of
lock checking for locks held by threads and by transactions{{.}} In this case,
there is no thread id update needed when thread for the transaction is switched.
What do you think about such solution?
> 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)
