[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760583#comment-16760583 ] Roman Kondakov commented on IGNITE-8841: [~gvvinblade], if so, the patch can be merged. > 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: 1.5h > 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)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760565#comment-16760565 ] Igor Seliverstov commented on IGNITE-8841: -- [~rkondakov], 1 - it's a pair method of MvccProcessor#requestReadSnapshotAsync() and, anyway, I going to use it in tests. 2 - Will fix. > 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: 1.5h > 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)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[
https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760147#comment-16760147
]
Roman Kondakov commented on IGNITE-8841:
[~gvvinblade], patch looks good for me. There are a couple of minor remarks:
# {{MvccProcessor#requestWriteSnapshotAsync()}} is not used anymore.
# {{MvccProcessorImpl.java:235}} blank lines in constructor.
> 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: 1.5h
> 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)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759873#comment-16759873 ] Ivan Pavlukhin commented on IGNITE-8841: [~gvvinblade] then everything looks ok to me. > 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)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759866#comment-16759866 ] Igor Seliverstov commented on IGNITE-8841: -- [~Pavlukhin] 1) Probably it makes sense, I left it like this not to change callers. Anyway we need to do some cleanup of involved classes, I've planned it as a separate task. 2) This is a special case, there can be active queries which survived several exchanges and there was no coordinator (no applicable for a coordinator node filter nodes) before new node have joined. We need to track such queries too. > 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)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[
https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759857#comment-16759857
]
Ivan Pavlukhin commented on IGNITE-8841:
[~gvvinblade] please find my comments below.
# Can we get rid of {{MvccUtils.requestSnapshot as it mostly delegates to
}}{{GridNearTxLocal}}?
# I did not get why do we need to call {{PreviousQueries.init}} from
{{onLocalJoin}} callback? It worth adding a comment explaining the idea.
> 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)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758247#comment-16758247 ] Igor Seliverstov commented on IGNITE-8841: -- I split the initial task into two parts - 1) turning the transaction into a read query (done in scope of this ticket) 2) allowing writes using newly acquired version (IGNITE-11173) [~rkondakov],[~Pavlukhin], [~amashenkov], [~vozerov], the first part is ready for review. Should I rewrite the ticket description according on made changes? > 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)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[
https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758230#comment-16758230
]
Ignite TC Bot commented on IGNITE-8841:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2965548buildTypeId=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)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[
https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=2965548buildTypeId=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)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[
https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754396#comment-16754396
]
Ignite TC Bot commented on IGNITE-8841:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2934593]]
* IgniteBinaryCacheQueryTestSuite:
IndexingCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodesWithPersistence
- 0,0% fails in last 428 master runs.
{color:#d04437}Java Client{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2934520]]
* IgniteClientTestSuite:
JettyRestProcessorAuthenticationWithTokenSelfTest.testVisorGateway - 0,0% fails
in last 432 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2934617buildTypeId=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: 10m
> 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)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746136#comment-16746136 ] Igor Seliverstov commented on IGNITE-8841: -- Actually the main problem is: a tx which obtained a snapshot but didn't do any updates isn't holding a topology lock, so nothing prevents a topology change. In case the topology change is caused by a coordinator failure, there is no info about such tx anymore, so, nothing prevents cleaning rows, which are still visible for such transaction. We need to track such txs like we do for query trackers and, after topology lock, acquire a new "write" snapshot as write version and continue reads using existed "read" snapshot but write using newly acquired write version. This way we meet consistency guaranties. > 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 >Priority: Major > Labels: failover > > 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)
