[ 
https://issues.apache.org/jira/browse/IGNITE-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16105031#comment-16105031
 ] 

Alexander Paschenko commented on IGNITE-5382:
---------------------------------------------

[~skalashnikov]
my comments:

- are we right to pass {{null}} as first arg when calling 
{{h2.executeSqlQueryWithTimer(null, c, "SELECT PLAN FROM "...}} in 
{{GridReduceQueryExecutor#explainPlan}}?

- please create an explicit class for new map's key in {{IgniteH2Indexing}}

- in {{IgniteH2Indexing#unregisterCache}}, we don't touch new {{connCache}} map 
at all, we should traverse all its elements and close/remove everything we 
don't need. Also we mutate {{conns}} without touching {{connCache}} in 
{{cancelAllQueries}} and {{stop}}. All in all I believe we should remove 
{{conns}} at all and leave map only - in fact, we don't benefit for it in any 
way (I don't see any random access cases for which Set semantic would be 
useful, we either always have a full key <Thread, Schema> or iterate over all 
collection anyway).






> SQL: frequent switch between schemas cause severe slowdown
> ----------------------------------------------------------
>
>                 Key: IGNITE-5382
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5382
>             Project: Ignite
>          Issue Type: Task
>          Components: cache, sql
>            Reporter: Vladimir Ozerov
>            Assignee: Sergey Kalashnikov
>              Labels: important, performance
>             Fix For: 2.2
>
>
> We have thread-bound cached connection to H2 database which is bound to 
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command, 
> which is rather expensive and may cause slowdown when queries form different 
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be 
> careful with concurrency and resource leaks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to