[jira] [Comment Edited] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.

["Igor Seliverstov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746136#comment-16746136 ] 

Igor Seliverstov edited comment on IGNITE-8841 at 1/18/19 10:31 AM:
--------------------------------------------------------------------

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'll meet consistency guaranties.


was (Author: gvvinblade):
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)