[jira] [Commented] (CALCITE-906) Avatica JdbcMeta statementCache id concurrency problem

["Julian Hyde (JIRA)" <ji...@apache.org>]

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

Julian Hyde commented on CALCITE-906:
-------------------------------------

Random is bad for the same reason that identityHashCode is bad, just longer gaps between clashes. I reckon about 2^16, per the birthday paradox.

I'm going to try AtomicInteger.

[~ndimiduk], [~vlsi], [~elserj] What do you think?

> Avatica JdbcMeta statementCache id concurrency problem
> ------------------------------------------------------
>
>                 Key: CALCITE-906
>                 URL: https://issues.apache.org/jira/browse/CALCITE-906
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Jan Van Besien
>            Assignee: Julian Hyde
>         Attachments: CALCITE-906.patch
>
>
> There seems to be a concurrency-related problem with the statementId that is generated in the JdbcMeta#createStatement for statements in the statementCache.
> We use avatica to create a driver which uses the remote RPC protocol to wrap an existing jdbc driver on the server. We have a test which performs concurrent queries on multiple connections (using apache commons-pool) which fails often.
> If it fails, the following two things are always observed:
> * A java.lang.AssertionError on the assert in Meta#count(String connectionId, int statementId, long updateCount), resulting in the server to send a http 500.
> * When logging all used connectionId's and statementId's, I observe the same statementId to be re-used for different connectionId's.
> I don't know exactly how these two problems are related, but it looks like statementId's are supposed to be unique and currently they are not.
> The current approach is  to use System.identityHashCode(statement) to calculate a statementId. Simply replacing this with a random int seems to solve the problem.
> Depending on what the actual uniqueness requirements for the statementId are, a UUID might be even better (but will have impact on the RPC) or an AtomicInteger.
> I'll attach a patch for the random int fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)