[
https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092904#comment-13092904
]
Rick Shaw commented on CASSANDRA-3091:
--------------------------------------
I think (in retrospect) I would clear the cache upon close for either approach
so it would force a reload on acquisition, so that may be a red herring. I
think the only issue is: is doing it in the statement any more expensive in
time vs the advantage of a more current set of metadata? If the general usage
pattern is to open a lot of statements vs opening connections, then it is
undeniably more time intensive to do in statement but the benefit is you would
SELDOM have mismatch with the state of the server. If the average use is to
open a connection and then open a statement and do all accesses on the
statement then its not really a penalty in time and the additional ability to
do a reload on demand when needed in the statement (at the price of the boolean
check for CF metadata) is a win.
If you think this is ill advised having said all that :) we can close the
ticket, and I'll put some of the additional cleanup of the {{ColumnDecoder}} in
another related patch at a later date. I could also look to see if I could get
the check for missing metadata against the data hanging off connection, but
that's along way from {{ColumnDecoder}} where the info is needed.
> Move the caching of KS and CF metadata in the JDBC suite from Connection to
> Statement
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-3091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
> 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: http://www.atlassian.com/software/jira
