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)
