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). Perhaps move from a single Connection member on JdbcMeta
to some factory that could getOrCreate Connections based on the caller's
properties?
I hadn't gotten to actually writing up my own test for the PHOENIX-1824
comment that James had made, but taking Jan's word, this is something
that will have to addressed in some manner for Phoenix :)
James Taylor wrote:
+1 to what Jan said. Phoenix relies on the connection properties to be
passed from client to server.
Thanks,
James
On Thursday, October 1, 2015, Jan Van Besien<[email protected]> wrote:
Julian,
I don't think Bruno's idea was to pass client connection properties
into the schema, but into the server-side connection (managed by
JdbcMeta). But before potentially drowning ourselves in details of the
implementation, maybe we should discuss whether the use case itself
makes sense (for avatica) first.
Our use case is to provide a thin-client variant of our existing JDBC
driver which behaves exactly the same as the existing "thick" jdbc
driver. The behavior of the existing driver currently depends on a
number of properties that can be set via the Properties instance
passed through the DriverManager.getConnection(url, props). We would
like users of the thin driver to be able to do this as well.
Furthermore, we would like to integrate a form of authentication in
the thin-client such that the client side credentials are used to
authenticate server side. I think this corresponds to what is
described in CALCITE-643.
If we don't pass client side properties to the server, and if we don't
have a one-to-one mapping of client side connections to server side
connections, I don't see how this use case is possible.
Our use case is actually very (if not completely) similar to what
apache-phoenix is doing with their query server [1]. They also use
connection properties (TenantId, CurrentSCN, ...) to influence the
behavior of the driver, and they suffer from the same problem (i.e.
these properties simply don't work through their QueryServer). I
started a discussion on the phoenix dev mailing list to see what their
ideas on this topic are, but at least some comments in PHOENIX-1824
[2] seem to suggest that they assume this should transparently work in
Avatica.
Thanks,
Jan
[1] https://phoenix.apache.org/server.html
[2]
https://issues.apache.org/jira/browse/PHOENIX-1824?focusedCommentId=14746605&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14746605
On Wed, Sep 30, 2015 at 6:35 PM, Julian Hyde<[email protected]
<javascript:;>> wrote:
A calcite schema is designed to be shared among multiple connections.
It might be created before the first connection (not currently, but
you could imagine a "Calcite server") and out-live all connections.
And it might be in use simultaneously by two connections: Fred and Bob
are both accessing Calcite and reading the EMP table via the CSV
adapter.
In that light, it doesn't make sense to pass the client's connection
properties (e.g. username = Bob) into the schema.
If we were to change schemas to what you are proposing, we would lose
a lot. E.g. the ability to cache.
On Wed, Sep 30, 2015 at 8:48 AM, Bruno Dumon<[email protected]
<javascript:;>> wrote:
It does seem a bit strange that there are Meta implementations which
wrap a
single connection, while at the same time some Meta methods
(createStatement) take a ConnectionHandle as parameter.
2015-09-30 17:41 GMT+02:00 Bruno Dumon<[email protected]
<javascript:;>>:
2015-09-30 17:23 GMT+02:00 Bruno Dumon<[email protected]
<javascript:;>>:
Hi,
I am looking into the same thing, and I think we need a "create
connection" operation in the avatica rpc, since these properties are
passed
at connection creation time. Right now connections are implicitly
created
when the client passes an unknown connection id.
On first sight the most logical place to do this is by adding a
connect()
method implementation to remote.Driver that performs the rpc to
create the
connection on the server. This would assume we have at that point
access to
Service.Factory, but that is not the case, as this is created by the
Connection itself by calling Driver.createMeta(). Another issue is
that it
is the AvaticaConnection constructor which decides on the connection
id. A
solution might be to refactor this so that these things are created
by the
driver and passed to the connection constructor (via
AvaticaFactory.newConnection), does this sound reasonable?
I overlooked the fact that some Meta implementations wrap the
connection,
so it is not easily possible to reverse this.
Ideas on how to approach adding a "create connection" rpc call
definitely
welcome :-)
--
Bruno
