[ 
https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16426905#comment-16426905
 ] 

Nikolay Izhikov commented on IGNITE-5714:
-----------------------------------------

[~Alexey Kuznetsov]

Let's make sure that:

1. We support backward compatibility for a network messages.
2. We don't allow user to use new feature unless some nodes in the cluster have 
version {{X-1}}. Where {{X}} is version when we merge this feature.

As far as I can see current changes contains changes for network messages. 
We need to address this issues to complete this task.

> Context switching 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: Alexey Kuznetsov
>            Priority: Major
>
> 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)

Reply via email to