Hello,
I couldn't find any recommendations on using calcite connection
(JdbcSchema) in a multi-threaded environment.
Probably throwing DataSource on the top of calcite connection is a wrong
thing to do since it doesn't create connections by itself rather delegates
to existing pools.
After creating a test [1], which simply executes a query from different
threads on the same connection, I run into some weird issue:
> Caused by: org.apache.calcite.avatica.NoSuchStatementException
> at
org.apache.calcite.jdbc.CalciteConnectionImpl$CalciteServerImpl.getStatement(CalciteConnectionImpl.java:371)
> at
org.apache.calcite.jdbc.CalciteConnectionImpl.getCancelFlag(CalciteConnectionImpl.java:238)
> at
org.apache.calcite.avatica.AvaticaStatement.<init>(AvaticaStatement.java:121)
> ... 17 more
It seems that non-atomic id increment is happening inside
org.apache.calcite.avatica.MetaImpl:213
```java
public StatementHandle createStatement(ConnectionHandle ch) {
// non-atomic connection.statementCount++
return new StatementHandle(ch.id, connection.statementCount++, null);
}
```
Can you confirm that Calcite connection (or more correctly
AvaticaConnection) is thread-safe by design ? If so, can this be considered
a bug ?
Regards,
Andrei
[1] https://gist.github.com/asereda-gs/cf0e1c0b8fa84a4cf3ceb6a21c9b11a8
