The general JDBC specification is that connections are not thread-safe. Only one thread should access a connection (or objects created from that connection, such as statements and result sets) at a time. The exception is the Statement.cancel() method, which can safely be called from another thread.
Calcite abides by that specification. (If we promised more than that we would probably have to reduce performance, and we would definitely have to increase testing.) In a multi-threaded environment the safest thing is for each thread to have its own connection. Julian > On Jun 14, 2019, at 11:05 AM, Andrei Sereda <[email protected]> wrote: > > 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
