[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757731#comment-16757731 ]
Ignite TC Bot commented on IGNITE-8841: --------------------------------------- {panel:title=--> Run :: All: Possible Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1} {color:#d04437}Cache (Restarts) 1{color} [[tests 5|https://ci.ignite.apache.org/viewLog.html?buildId=2965493]] * IgniteCacheRestartTestSuite: GridCacheReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups - 0,0% fails in last 390 master runs. {panel} [TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=2965548&buildTypeId=IgniteTests24Java8_RunAll] > MVCC TX: Read transactions remap when coordinator fails. > -------------------------------------------------------- > > Key: IGNITE-8841 > URL: https://issues.apache.org/jira/browse/IGNITE-8841 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql > Reporter: Roman Kondakov > Assignee: Igor Seliverstov > Priority: Major > Labels: failover > Time Spent: 50m > Remaining Estimate: 0h > > At the moment read transactions that don't acquire topology lock will be > forcibly rolled back on topology change as read tx can be in fly while > topology being change. > This is done to prevent having active transaction with stale snapshots on > new topology in cases of TX coordinator or Near node were lost. > > It would be nice to remap it somehow until they locked a topology or at least > throw some meaningful exception to user. > For example, it is possible to obtain a new "write" mvcc version from the > new coordinator and use this version for all further writes while using "old" > version for reads. In this case we need to change visibility rules a little: > "old" version should see "own" updates made by "new" "write" version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)