[
https://issues.apache.org/jira/browse/IGNITE-11173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-11173:
--------------------------------------
Fix Version/s: 2.8
> 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: New Feature
> Components: mvcc
> Reporter: Igor Seliverstov
> Priority: Major
> Fix For: 2.8
>
>
> 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
(v7.6.3#76005)
