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

["Jan Van Besien (JIRA)" <ji...@apache.org>]

Jan Van Besien created CALCITE-906:
--------------------------------------

             Summary: 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


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)