[
https://issues.apache.org/jira/browse/IGNITE-20116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20116:
-------------------------------------
Priority: Blocker (was: Major)
> Linearize storage updates with safeTime adjustment rules
> --------------------------------------------------------
>
> Key: IGNITE-20116
> URL: https://issues.apache.org/jira/browse/IGNITE-20116
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Blocker
> Labels: ignite-3, transactions
>
> h3. Motivation
> The logic of setting safeTime explicitly prohibits setting a larger time
> ahead of a smaller one. In other words, all data updates within storages
> should be strictly ordered by the safeTime associated with such updates.
> Currently it's not true:
> * We associate update and safe time during update command creation (see
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener)
> {code:java}
> UpdateCommandBuilder bldr = MSG_FACTORY.updateCommand()
> ...
> .safeTimeLong(hybridClock.nowLong()); {code}
> * However, neither applying a given command locally nor sending it to the
> raft isn't linearized with associated safeTime value. In other words, it's
> possible that we will assign t0 to the cmd0 and t1 to the cmd1 but will apply
> cmd1 prior to cmd0 locally.
> Simply speaking, we lack some sort of synchronization here.
> h3. Definition of Done
> * It's required to add an assert that will verify that we never ever try to
> update a safeTime with a smaller or equal value.
> * It's required to linearize updates application to preserve guarantees of
> the monotonicity of a safeTime's adjustment.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
