Description
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.
Attachments
Attachments
Issue Links
- is related to
-
CALCITE-4489 Avatica JdbcMeta statement IDs Concurrency problem
-
- Closed
-
-
CALCITE-924 Ensure connectionIDs are unique
-
- Open
-