I'd rather go in the direction of JdbcMeta having as little state as possible. The principle is that if you ask the same question, you get the same answer.
The caches necessary to manage connections and statements from the underlying JDBC data source add a little state, but we should stop adding state there. I believe that JdbcMeta should be based off a single connection specification (url + info). If you want another connection specification, create another JdbcMeta. On Thu, Oct 1, 2015 at 12:42 PM, Josh Elser <[email protected]> wrote: > Bruno Dumon wrote: >>> >>> Maybe JdbcMeta just gets a cache of Drivers tied to a set of properties? >>> > Reusing ConnectionProperties (via the ConnectionSyncRequest RPC) seems >>> > to >>> > make sense to me from a lifecycle sense for now (perhaps ultimately >>> > moving >>> > towards encapsulating this state in each RPC to help with the >>> > statelessness). >> >> >> >> Hmm, stateless jdbc connections, is that possible? Maybe if it is just for >> read, but even then it seems challenging. >> > > See https://issues.apache.org/jira/browse/CALCITE-903 for the current > approach.
