[
https://issues.apache.org/jira/browse/IGNITE-23806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-23806:
-------------------------------------
Description:
h3. Motivation
An RO transaction at the start is associated with a certain readTimestamp. As
part of processing the RO request on the replica side, we wait for safeTime to
become greater than or equal to readTimestamp. SafeTime on the replica is
updated by the user load, and in case of its absence, by a special mechanism -
idle SafeTime propagaion. All this leads to the fact that RO, whose
readTimestamp is calculated as now(), will almost always wait for the safeTime
to be increased on the replica, if there is no user load, up to a second. In
order to eliminate this wait when calculating readTimestamp, we omit
idleSafeTimeSyncInterval, or, to be precise, clock.now -
IDLE_SAFE_TIME_INTERVAL - maxClockSkew()
h3. Definition of Done
* Define set of protocols that should adjust maxObservableTimestamp.
** Transactions.
** DDL.
** Compute
** ???
* Design generalised protocol in order to adjust maxObservalbeTimestamp on
both client and embedded node. Currently we have one only for transactions.
was:
h3. Motivation
An RO transaction at the start is associated with a certain readTimestamp. As
part of processing the RO request on the replica side, we wait for safeTime to
become greater than or equal to readTimestamp. SafeTime on the replica is
updated by the user load, and in case of its absence, by a special mechanism -
idle SafeTime propagaion. All this leads to the fact that RO, whose
readTimestamp is calculated as now(), will almost always wait for the safeTime
to be increased on the replica, if there is no user load, up to a second. In
order to eliminate this wait when calculating readTimestamp, we omit
idleSafeTimeSyncInterval, or, to be precise, clock.now -
IDLE_SAFE_TIME_INTERVAL - maxClockSkew()
h3. Definition of Done
* Investigate all protocols like compute and DDL in order
> Investigate the possibility of generalizing the logic for working with
> maxObservableTimestamp.
> ----------------------------------------------------------------------------------------------
>
> Key: IGNITE-23806
> URL: https://issues.apache.org/jira/browse/IGNITE-23806
> Project: Ignite
> Issue Type: Task
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> An RO transaction at the start is associated with a certain readTimestamp. As
> part of processing the RO request on the replica side, we wait for safeTime
> to become greater than or equal to readTimestamp. SafeTime on the replica is
> updated by the user load, and in case of its absence, by a special mechanism
> - idle SafeTime propagaion. All this leads to the fact that RO, whose
> readTimestamp is calculated as now(), will almost always wait for the
> safeTime to be increased on the replica, if there is no user load, up to a
> second. In order to eliminate this wait when calculating readTimestamp, we
> omit idleSafeTimeSyncInterval, or, to be precise, clock.now -
> IDLE_SAFE_TIME_INTERVAL - maxClockSkew()
> h3. Definition of Done
> * Define set of protocols that should adjust maxObservableTimestamp.
> ** Transactions.
> ** DDL.
> ** Compute
> ** ???
> * Design generalised protocol in order to adjust maxObservalbeTimestamp on
> both client and embedded node. Currently we have one only for transactions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
