Julian> Indeed, JDBC itself is not thread-safe Just in case: CalciteRemoteDriverTest seems to be pretty sane test (it does not use the same java.sql.Connection across multiple threads), yet it fails with race-condition-like reasons.
I won't really want to dig into JDBC thread-safety, however that is a slippery slope. I used to think that JDBC is not thread-safe, however now I don't think so (after being pgjdbc maintainer for a several years). For instance, there's Connection#getWarnings, and clients expect that to work from a separate thread while statement is still running (and producing warnings). There's #close which apparently should be thread-safe (e.g. to play well with automatic flnalize-like cleanup). Threre's Connection#abort, and so on. Julian> So, the solution is not necessarily to add locks and/or synchronized all over MetaImpl. Apparently the solution is to replace "connection" and "connProps" fields of MetaImpl with Map<ConnectionId, ...> kind of field. It is really hard to imagine a HTTP service that produces correct results only in case it is accessed from within a single connection only. For instance, connectionSync is a separate wire command, so currently it just overwrites MetaImpl field, and it is pretty close to plug&pray kind of technology. I wonder how it managed to survive for such a long go. I'm not sure how much sense MetaImpl(AvaticaConnection connection) constructor parameter makes. I think connection creation should happen in org.apache.calcite.avatica.MetaImpl#openConnection Of course, MetaImpl might want to have a connection instance for calls like catalogs(), then it could just call openConnection on its own and that's it. Am I missing something? Vladimir
