cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Shaw (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
Date Mon, 29 Aug 2011 14:32:37 GMT


Rick Shaw commented on CASSANDRA-3091:

It is cached in the statement as well so it will do the fetch one time when the statement
is first created and then just check the cache to make sure the metadata is there and attempt
a reload only if it does not find it. Once you acquire a statement you usually hold on to
it for the duration of your task. So not significantly more than if you acquired a connection.

> Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
> -------------------------------------------------------------------------------------
>                 Key: CASSANDRA-3091
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Drivers
>    Affects Versions: 0.8.4
>            Reporter: Rick Shaw
>            Assignee: Rick Shaw
>            Priority: Minor
>              Labels: JDBC
>             Fix For: 0.8.5
>         Attachments: move-metadata-for decoder-to-statement-level-v1.txt, move-metadata-for-decoder-to-statement-level-v2.txt
> Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is loaded and
held in the {{CassandraConnection}} class. The implication of this is that any activity on
the connected server from the time the connection is established is not reflected in the KSs
and CF that can be accessed by the {{ResultSet, Statement}} and {{PreparedStatement}}.
> By moving the cached metadata to the {{Statement}} level, the currency of the metadata
can be checked within the {{Statement}} and reloaded if it is seen to be absent. And by instantiating
a new {{Statement}} (on any existing connection) you are assured of getting the most current
copy of the metadata known to the server at the new time of instantiation.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message