[
https://issues.apache.org/jira/browse/IGNITE-18203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-18203:
-------------------------------------
Description:
Currently, index depends on a table, while table depends on RAFT groups start,
which may need to apply commands (including inserts), and inserts depend on
indices of the table. There is a dependency cycle. This is just one example of
such a cycle in the current design.
One idea is to split 'Table' entity into 2: 'Table Structure' and 'Full Table'.
Table structure would only comprise objects representing bare table information
(no indices), something like current {{{}TableImpl{}}}/{{{}InternalTable{}}}.
Then, the following dependencies could be created:
# Table Structure depends on Configuration
# Index depends on Configuration and Table Structure
# Sql Schema depends on Table Structure and Index
# Full Table depends on Table Structure, Index, Sql Schema
This requires a redesign of how {{{}TableManager{}}}, {{{}IndexManager{}}},
{{SqlSchemaManager}} interact, probably {{TableManager}} needs to be broken in
2.
*Upd*
I've tried to redesign the TableManager in order to split the table into two
parts: schema based "client" one (used by indeces, etc) and the one that
assumes starting server endpoints. Unfortunately I didn't succeed in it. We
will have one more attempt within distribution zone collocation related issues.
Thus in order to fix the deadlock I've proposed rather crappy solution with
async raft log application on restart based on the latch that bind
PartitionReplicaListener.invoke and NodeImpl together. Ugly one that hopefully
will be eliminated in the future.
was:
Currently, index depends on a table, while table depends on RAFT groups start,
which may need to apply commands (including inserts), and inserts depend on
indices of the table. There is a dependency cycle. This is just one example of
such a cycle in the current design.
One idea is to split 'Table' entity into 2: 'Table Structure' and 'Full Table'.
Table structure would only comprise objects representing bare table information
(no indices), something like current {{{}TableImpl{}}}/{{{}InternalTable{}}}.
Then, the following dependencies could be created:
# Table Structure depends on Configuration
# Index depends on Configuration and Table Structure
# Sql Schema depends on Table Structure and Index
# Full Table depends on Table Structure, Index, Sql Schema
This requires a redesign of how {{{}TableManager{}}}, {{{}IndexManager{}}},
{{SqlSchemaManager}} interact, probably {{TableManager}} needs to be broken in
2.
*Upd*
I've tried to redisn
> Redesign table/index creation to avoid dependency cycles
> --------------------------------------------------------
>
> Key: IGNITE-18203
> URL: https://issues.apache.org/jira/browse/IGNITE-18203
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Assignee: Alexander Lapin
> Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Currently, index depends on a table, while table depends on RAFT groups
> start, which may need to apply commands (including inserts), and inserts
> depend on indices of the table. There is a dependency cycle. This is just one
> example of such a cycle in the current design.
> One idea is to split 'Table' entity into 2: 'Table Structure' and 'Full
> Table'. Table structure would only comprise objects representing bare table
> information (no indices), something like current
> {{{}TableImpl{}}}/{{{}InternalTable{}}}. Then, the following dependencies
> could be created:
> # Table Structure depends on Configuration
> # Index depends on Configuration and Table Structure
> # Sql Schema depends on Table Structure and Index
> # Full Table depends on Table Structure, Index, Sql Schema
> This requires a redesign of how {{{}TableManager{}}}, {{{}IndexManager{}}},
> {{SqlSchemaManager}} interact, probably {{TableManager}} needs to be broken
> in 2.
>
> *Upd*
> I've tried to redesign the TableManager in order to split the table into two
> parts: schema based "client" one (used by indeces, etc) and the one that
> assumes starting server endpoints. Unfortunately I didn't succeed in it. We
> will have one more attempt within distribution zone collocation related
> issues. Thus in order to fix the deadlock I've proposed rather crappy
> solution with async raft log application on restart based on the latch that
> bind PartitionReplicaListener.invoke and NodeImpl together. Ugly one that
> hopefully will be eliminated in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
