[
https://issues.apache.org/jira/browse/IGNITE-20116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20116:
-------------------------------------
Description:
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 linearize updates application to preserve guarantees of the
monotonicity of a safeTime's adjustment.
was:
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.
> 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 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)
