2015-10-01 19:17 GMT+02:00 Josh Elser <[email protected]>: > So, the concrete issue I see presently is that JdbcMeta gets a fixed set > of Properties (when it's instantiated) and uses those properties to make a > single Connection for all calls. > > 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. > Perhaps move from a single Connection member on JdbcMeta to some factory > that could getOrCreate Connections based on the caller's properties? > JdbcMeta already manages client-specific connections, the single connection is marked for removal: private final Connection connection; // TODO: remove default connection private final Cache<String, Connection> connectionCache; I did manage to add an OpenConnection rpc request that allows passing properties, and it seems to work just fine, though the implementation does make one strange jump. I'll look tomorrow to share it via jira. -- Bruno
