[
https://issues.apache.org/jira/browse/IGNITE-20108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-20108:
----------------------------------------
Fix Version/s: 3.2
(was: 3.1)
> 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.2
>
>
> h3. This design is problematic
> This might lead to the following:
> # A transaction is started
> # It touches table A
> # Column c1 is added to tables A and B
> # The transactin touches table B
> # Now, it sees old version of A without A.c1, but new version of B with
> B.c1, which seems to be inconsistent
> Probably this has to be redesigned (or at least examined carefully). There is
> an alternative in IGNITE-21003.
> h2. The design
> [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)
