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