+1 what Josh said. Also: non-thread-safe is not necessarily a bad thing. As long as the caller knows the limitation. Code that is written only to work single-threaded is more efficient and has fewer bugs.
Indeed, JDBC itself is not thread-safe. It is not safe for two threads to access the same Connection, Statement or ResultSet at the same time. (With a special exception for the Statement.cancel() method.) So, the solution is not necessarily to add locks and/or synchronized all over MetaImpl. Julian > On Feb 14, 2019, at 2:46 PM, Josh Elser <[email protected]> wrote: > > The Meta implementation inside of the Avatica server is a singleton, so yes > the implementation must be threadsafe as the server will dispatch multiple > user request threads to it. The Meta implementation is largely (by virtue of > the wire API) stateless. I think the expectation should be that all Meta > implementations are threadsafe, but this probably isn't something anything > has really looked long and hard at. > > On 2/14/19 3:15 PM, Vladimir Sitnikov wrote: >> Hi, >> CalciteRemoteDriverTest seems to be very unstable at >> https://builds.apache.org/job/Calcite-Master/ >> I guess the problem there is the test is using a single CalciteMetaImpl >> object to handle all the requests. >> Apparently CalciteMetaImpl is using no synchronization and it uses simple >> HashMaps (Meta is associated with exactly one Connection which is not >> thread-safe). >> I wonder: >> 1) Is org.apache.calcite.avatica.Meta supposed to be thread-safe? Javadoc >> does not clarify that. It looks >> like org.apache.calcite.avatica.jdbc.JdbcMeta is thread-safe. >> 2) In case Meta is supposed to be thread-safe, >> why org.apache.calcite.avatica.MetaImpl has Connection constructor? Does >> Avatica suppose that all connection implementations are thread-safe? >> 3) In case Meta is supposed to be thread-safe, how MetaImpl#connProps is >> supposed to work? Apparently different connections might have different >> properties (e.g. autocommit settings), so how a single connProps would fit >> all? >> 4) In case Meta is not supposed to be thread-safe, >> why org.apache.calcite.avatica.server.Main#start uses just a single Meta >> object to handle all the requests? >> 5) Does anybody use CalciteRemoteServer at all? >> I don't have Calcite-remote use-cases yet, however the current state of >> builds.apache.org is useless as it fails extremely often. >> Vladimir
