[
https://issues.apache.org/jira/browse/CALCITE-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17109687#comment-17109687
]
Stamatis Zampetakis commented on CALCITE-3999:
----------------------------------------------
I was mostly afraid of the fact that we use a connection while keeping a lock
so there are various things that can go wrong and get blocked there. However,
by properly configuring the datasource this risk becomes rather small. Moreover
keeping the cache has a smaller risk for regressions. For the previous reasons
as well those mentioned by [~jcamachorodriguez] the best option is most likely
to keep the Guava cache introduced in PR#1977.
+1
> Simplify DialectPool implementation using Guava cache
> -----------------------------------------------------
>
> Key: CALCITE-3999
> URL: https://issues.apache.org/jira/browse/CALCITE-3999
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Jesus Camacho Rodriguez
> Assignee: Jesus Camacho Rodriguez
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JdbcUtils contains a pool to cache SqlDialect objects. Currently, it relies
> on multiple maps and a synchronized {{get}} method. Although I am not very
> familiar with that code, it seems the implementation could be made simpler
> and more efficient by using a Guava cache. In addition, since we would not
> have a single synchronized get method, multiple threads could concurrently
> create dialects for distinct data sources.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
