[jira] [Updated] (IGNITE-11173) MVCC TX: Acquire write version if coordinator changed in the middle of tx.

["Maxim Muzafarov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-11173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maxim Muzafarov updated IGNITE-11173:
-------------------------------------
    Fix Version/s:     (was: 2.8)
                   2.9

> MVCC TX: Acquire write version if coordinator changed in the middle of tx.
> --------------------------------------------------------------------------
>
>                 Key: IGNITE-11173
>                 URL: https://issues.apache.org/jira/browse/IGNITE-11173
>             Project: Ignite
>          Issue Type: Task
>          Components: mvcc
>            Reporter: Igor Seliverstov
>            Priority: Major
>             Fix For: 2.9
>
>
> Current implementation suppose all transactions on previous coordinator were finished before new coordinator has been initialized, but there is a case when it isn't true. 
> A tx which hasn't obtained a topology lock (hasn't done any updates) doesn't prevent a topology change, this way nothing prevent new transactions start.
> All newly created txs suppose all updates on previous coordinator are finished - this mean a possible update of mapped on previous coordinator txs is considered as stale regardless the tx is still active. We make such txs readonly to not break the visibility checking logic (see IGNITE-8841).
> There are two possible ways to allow writes after coordinator is changed:
> * collect active txs and their dependencies and populate the active txs list with them during a new coordinator initialization - this approach is quite complex and have obvious issues like necessity of using full tx versions in a snapshot
> * acquire a new version right after topology locked for writes using previously acquired "read" version for possible write conflicts detecting and visibility checking.
> I would prefer the second option as fully understandable and relatively easy to implement.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)