[
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:29 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 (for example remove
methods like {{lockedLocallyByIdOrThread).}} 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)
