cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandeep Tamhankar (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CASSANDRA-12574) Make connections state-less; do not bind a keyspace to the connection
Date Wed, 31 Aug 2016 16:02:22 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sandeep Tamhankar resolved CASSANDRA-12574.
-------------------------------------------
    Resolution: Duplicate

> Make connections state-less; do not bind a keyspace to the connection
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-12574
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12574
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Sandeep Tamhankar
>
> Currently, when a client does a "USE <keyspace>", the connection is bound to that
keyspace. If an application interacts with multiple keyspaces, it must create a new connection
for each keyspace if it wants to continue to use un-qualified cql. This is particularly onerous
on "gateway" apps like DataStax Studio, which act on behalf of many users and currently have
to open many connections. This is also an annoyance to driver developers.
> Proposal:
> * Support a keyspace argument in the custom payload of cql requests. Since custom payloads
are already supported in the wire protocol as of v4, no protocol change is needed.
> * This value, if present, takes precedence over the keyspace bound to the connection
(if present).
> C* Drivers, which currently issue "USE <ks>" statements when creating a session
would now just store the desired default ks and when issuing requests, supply the desired
keyspace in the custom payload.
> The net effect is that the drivers no longer need to create separate connection pools
for different sessions. Also, because the feature doesn't involve a protocol change, it can
be implemented in the next 3.x release as well as 2.x, so users who aren't ready to upgrade
to 3.x yet can still benefit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message