[jira] [Updated] (IGNITE-20108) Use tableEnlistTs as baseTs when validating schema

["Roman Puchkovskiy (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-20108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Roman Puchkovskiy updated IGNITE-20108:
---------------------------------------
    Epic Link: IGNITE-20800  (was: IGNITE-18733)

> Use tableEnlistTs as baseTs when validating schema
> --------------------------------------------------
>
>                 Key: IGNITE-20108
>                 URL: https://issues.apache.org/jira/browse/IGNITE-20108
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Roman Puchkovskiy
>            Priority: Major
>              Labels: iep-110, ignite-3
>             Fix For: 3.0.0-beta2
>
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes#IEP110:Schemasynchronization:basicschemachanges-Basicrequirements requires an ALTER TABLE occurring after a transaction had started but before the tx touched the table for the first time to be visible to the tx and not cause its abortion.
> To achieve this, we should take baseTs=tableEnlistTs(tx, table).
> Both tx coordinator and primary need to track those tableEnlistTs. On the coordinator and the primary these values will most likely be different (because they are taken from different clocks: the coordinator clock and the primary clock), but this is acceptable.
> h3. Coordinator
> The  coordinator already tracks some information about a transaction (namely, its enlisted partitions); tableEnlistTs should be added to this structure. When doing the client schema version check (IGNITE-20106), the coordinator should check whether tableEnlistTs already exists for the table in question, and, if not, generate it (as HLC.now()) and remember it; then use it to obtain the server-side schema version and use the version to validate the client's request.
> h3. Primary
> The primary should track tableEnlistSchemaVersion too. It should make sure that the coordinator's tableEnlistSchemaVersion (that can be determined by the schema version of the tuples that the client sends) matches the primary's tableEnlistSchemaVersion (that is determined by the operationTs (on the primary clock) of the first operation touching the table in the transaction.
> On recovery, the primary should recover tableEnlistSchemaVersions; it can do so by scanning all writes made by a transaction and looking into Schema Version mentioned in the corresponding tuples.



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