[ https://issues.apache.org/jira/browse/IGNITE-20116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Lapin updated IGNITE-20116: ------------------------------------- Issue Type: Bug (was: Improvement) > Linearize storage updates with safeTime adjustment rules > -------------------------------------------------------- > > Key: IGNITE-20116 > URL: https://issues.apache.org/jira/browse/IGNITE-20116 > Project: Ignite > Issue Type: Bug > 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)