[
https://issues.apache.org/jira/browse/CASSANDRA-9770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-9770.
-----------------------------------------
Resolution: Invalid
See my comment on CASSANDRA-9768.
> Expose API to load prepare statement based on preparedId
> --------------------------------------------------------
>
> Key: CASSANDRA-9770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9770
> Project: Cassandra
> Issue Type: Bug
> Components: Drivers (now out of tree)
> Environment: Cassandra 2.0.16
> Java driver 2.1.6
> Ubuntu 15.04
> Reporter: Ajay
> Fix For: 2.1.6
>
>
> Currently whenever client calls session.prepare(Statement), the Java driver
> prepares the statement with cassandra. Cassandra prepares the statement,
> caches in memory and returns prepareId. The driver caches it in the session
> and uses it subsequently.
> In case, we have another session (as in web application or REST services,
> there are multiple JVM and so different cluster and session instances),
> currently we need reprepare the same query for which we need the original
> query string and other details (like consistency level and so on).
> Since cassandra is already caching in memory (also a ticket is there to
> persist as well in 3.x), we can have an API to load the preparestatement from
> any session (if not there in the cache already) as below
> Session.loadPreparedStatement(MD5Digest id)
> where the driver can call Cassandra and load the preparedstatement (to get
> metadata, resultSetMetadata, routingKeyIndexes etc...).
> WIth this, the client need to cache only the prepareId and can avoid multiple
> round trip to prepare the query (same query) again with different hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
