[IGNITE-6173] SQL: do not start caches on client nodes

• Type: Task
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.1
• Fix Version/s: 2.8
• Component/s: cache, sql
• Labels: sql-stability
• Assignee: Iurii Gerzhedovich
• Reporter: Vladimir Ozerov
• Created: 23/Aug/17 14:43
• Updated: 24/Sep/20 10:18
• Resolved: 03/Dec/18 11:23

Description

When cache is started, this even is distributed through custom discovery message. Server nodes start the cache, client nodes do nothing until cache is requested explicitly. At the same time H2 database objects are created only when cache is really started.

For this reason query parsing could lead to TABLE NOT FOUND, INDEX NOT FOUND, etc. errors. If such exception is observed, we force start of all known cache on a client and then retry. See GridCacheProcessor#createMissingQueryCaches method.

First, client node cache start leads to another custom discovery message. So query performance may suffer. Second, this is not needed! We already have all necessary cache info in discovery.

Let's try to find a way to use available discovery data and do not start cache on a client for SQL query execution.

Issue Links

• blocks: IGNITE-9989 JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME
• blocks: IGNITE-10118 JDBC v2: metadata.getSchemas returns cache names instead of schema names
• causes: IGNITE-13482 Client node cannot ALTER TABLE if it was created on a different node
• is duplicated by: IGNITE-8060 Sqline creating tables on client nodes works incorrect in case of node's shutdown
• is duplicated by: IGNITE-8100 jdbc getSchemas method could miss schemas for not started remote caches
• is duplicated by: IGNITE-8055 Sqline command !tables works incorrect for client node
• is duplicated by: IGNITE-4957 First join query execution in client mode takes too long when there are many caches on remote nodes
• links to: latest test results
• links to: MVCC Cache test results
• links to: PR link