[
https://issues.apache.org/jira/browse/IGNITE-21192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-21192:
---------------------------------------
Description:
SchemaManager writes table's schema version to the MetaStorage as soon as the
table is created/altered in the Catalog. The Catalog events are triggered by
the MetaStorage events handling in MetaStorage watches. The future for writing
to the MetaStorage (when saving the table schema version) is returned from the
event handler by SchemaManager, so, effectively, the write to the MS blocks
finishing processing of MS events, which in turn might block leases and schema
sync, causing problems.
Including the writing part to the future of handling the original watch event
if handy because this gives us a pretty strong guarantee: if a Catalog version
is active on the node, then SchemaManager's table schemas corresponding to this
version are also available on the node.
Currently, we make sure that a node can see a tuple written in a schema version
only after the node sees the corresopnding Catalog version. We can extend this
by also waiting for SchemaManager's table version corresponding to the Catalog
version to be available on the node. Having this, we will be able to drop the
requirement for the future chaining.
> SchemaManager operation should not block MetaStorage watches
> ------------------------------------------------------------
>
> Key: IGNITE-21192
> URL: https://issues.apache.org/jira/browse/IGNITE-21192
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> SchemaManager writes table's schema version to the MetaStorage as soon as the
> table is created/altered in the Catalog. The Catalog events are triggered by
> the MetaStorage events handling in MetaStorage watches. The future for
> writing to the MetaStorage (when saving the table schema version) is returned
> from the event handler by SchemaManager, so, effectively, the write to the MS
> blocks finishing processing of MS events, which in turn might block leases
> and schema sync, causing problems.
> Including the writing part to the future of handling the original watch event
> if handy because this gives us a pretty strong guarantee: if a Catalog
> version is active on the node, then SchemaManager's table schemas
> corresponding to this version are also available on the node.
> Currently, we make sure that a node can see a tuple written in a schema
> version only after the node sees the corresopnding Catalog version. We can
> extend this by also waiting for SchemaManager's table version corresponding
> to the Catalog version to be available on the node. Having this, we will be
> able to drop the requirement for the future chaining.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
