[ 
https://issues.apache.org/jira/browse/IGNITE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17797268#comment-17797268
 ] 

Roman Puchkovskiy commented on IGNITE-21084:
--------------------------------------------

Thanks!

> Account for differences of logical part of now() on different nodes when 
> waiting after a DDL
> --------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-21084
>                 URL: https://issues.apache.org/jira/browse/IGNITE-21084
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Roman Puchkovskiy
>            Assignee: Roman Puchkovskiy
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.0.0-beta2
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Client must see the results of a DDL they just executed, no matter through 
> which node of the cluster a subsequent request is made. To maintain this, we 
> must make sure that ActivationTimestamp(DDL) becomes non-future on all nodes 
> of the cluster and only then can we complete the DDL future. As nodes' 
> physical clocks might have some skew relatively to each other, we add 
> MaxClockSkew to the timestamp till which we wait to compensate for this 
> difference.
> Analogously to HLC.now() being different because its physical part differs on 
> different nodes, it might be different because *logical* parts are different 
> on different nodes.
> Let's assume we don't have any physical clock skew, and MaxClockSkew is 0. 
> ActivationTimestamp(DDL) is (100, 5); (100 is physical part, 5 is logical 
> part). We wait on node 1 (through which the DDL was executed) till its 
> HLC.now() reaches (100, 5), then we complete the DDL future. The user goes to 
> node 2 at which HLC.now() is (100, 2). The user executes a query at 'now', 
> and the query sees the state before the DDL was executed, which breaks our 
> requirement.
> We can fix this by 'rounding' the timestamp-to-wait-for up in the following 
> way:
>  # If logical part is not 0, increment the physical part and set the logical 
> part to 0
>  # If the logical part is 0, leave the timestamp as is
> As a result, for (100, 0) we will wait for (100, 0), and at node 1 HLC is at 
> least (100, 0), so it cannot see the previous schema. For (100, 5) we would 
> wait till (101, 0), which would also guarantee that a query executed after 
> waiting sees the new schema version.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to