[ 
https://issues.apache.org/jira/browse/IGNITE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Pavlukhin reassigned IGNITE-9944:
--------------------------------------

    Assignee: Ivan Pavlukhin

> MVCC TX: GridDhtTxAbstractEnlistFuture near nodes update race.
> --------------------------------------------------------------
>
>                 Key: IGNITE-9944
>                 URL: https://issues.apache.org/jira/browse/IGNITE-9944
>             Project: Ignite
>          Issue Type: Bug
>          Components: mvcc
>            Reporter: Roman Kondakov
>            Assignee: Ivan Pavlukhin
>            Priority: Major
>             Fix For: 2.7
>
>
> When {{GridDhtTxAbstractEnlistFuture#skipNearNodeUpdates}} is set to true it 
> can cause failure on backup node during rebalancing. Possible scenario:
> # First entry is enlisted before rabalance was started and therefore it's 
> backup node is added to {{GridDhtTxLocalAdapter#addLockTransactionNode}} in 
> {{GridDhtTxAbstractEnlistFuture#addToBatch}} method. Note: in this case 
> remote tx is not started on remote note.
> # Next entry could be processed when rebalance is already started and 
> therefore this optimization will be skipped. In this case updated entry will 
> be sent to backup node as usual in DhtEnlistRequest. 
> # But instead of sending {{GridDhtTxQueryFirstEnlistRequest}}, the 
> {{GridDhtTxQueryEnlistRequest}} will be sent because near node has already 
> been added to tx lock nodes list.
> # When this request arrives in 
> {{GridDhtTransactionalCacheAdapter#processDhtTxQueryEnlistRequest}}, the "Can 
> not find a transaction" exception will be thrown.
> Possible solution: we need to send {{GridDhtTxQueryFirstEnlistRequest}} in 
> these cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to