[
https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859149#comment-16859149
]
Igor Seliverstov edited comment on IGNITE-5714 at 6/9/19 4:25 PM:
------------------------------------------------------------------
Rolling update is out of scope there since Ignite doesn't support it.
I meant you may use a thread local variable to hold explicit lock version (with
a counter represents how many locks you hold). At first lock operation you
generate a new GridCacheVersion, put it into the variable and use it for
locking. On locks release you decrement the counter and remove the version as
soon as the counter becomes zero. So you have tx version and explicit lock
version at the hand. This way you don't need txFinishSync since there is
nothing to defend with it.
Possible some changes at message layer needed.
was (Author: gvvinblade):
Rolling update its or of scope there since Ignite doesn't support it.
I meant you may use a thread local variable to hold explicit lock version (with
a counter represents how many locks you hold). At first lock operation you
generate a new GridCacheVersion, put it into the variable and use it for
locking. On locks release you decrement the counter and remove the version as
soon as the counter becomes zero. So you have tx version and explicit lock
version at the hand. This way you don't need txFinishSync since there is
nothing to defend with it.
Possible some changes at message layer needed.
> 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: 4h 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)
