[
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)