You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Rick Shaw (JIRA)" <ji...@apache.org> on 2011/08/28 05:59:37 UTC
[jira] [Created] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
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
Fix For: 0.8.5
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
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Rick Shaw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092862#comment-13092862 ]
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: 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
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092887#comment-13092887 ]
Jonathan Ellis commented on CASSANDRA-3091:
-------------------------------------------
What would that look like with statement pooling?
> 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
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Rick Shaw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097178#comment-13097178 ]
Rick Shaw commented on CASSANDRA-3091:
--------------------------------------
Let's close this in deference to CASSANDRA-2734, and get that into trunk.
> 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.6
>
> 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
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092853#comment-13092853 ]
Jonathan Ellis commented on CASSANDRA-3091:
-------------------------------------------
I feel like the cure might be worse than the disease here. Schema typically only changes "underneath" a connection during development -- if you're changing schema in production, you're going to redeploy your app to take advantage of that, creating new connections. So the benefit feels small vs the cost of re-requesting and parsing metadata for each Statement.
> 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
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092866#comment-13092866 ]
Jonathan Ellis commented on CASSANDRA-3091:
-------------------------------------------
But connections are (or will be) pooled. Statements are not.
> 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
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092873#comment-13092873 ]
Jonathan Ellis commented on CASSANDRA-3091:
-------------------------------------------
I suppose, but if you're pooling statements, how is making metadata per-statement a win?
> 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
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Rick Shaw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092869#comment-13092869 ]
Rick Shaw commented on CASSANDRA-3091:
--------------------------------------
In JDBC you can pool both!
> 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
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Rick Shaw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092877#comment-13092877 ]
Rick Shaw commented on CASSANDRA-3091:
--------------------------------------
This approach puts the caller in better control of when the refreshed data is acquired. It is easy to close one statement and reacquire. If you do with a pooled resource it will not reacquire until the physical connection goes stale from no use. On a busy system and when the app acquires the connection itself infrequently, it may be a long time before you see a new refreshed set of data in a new connection.
> 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
[jira] [Updated] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Rick Shaw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Shaw updated CASSANDRA-3091:
---------------------------------
Attachment: move-metadata-for-decoder-to-statement-level-v2.txt
v2 of patch adds better clarity to the non-interface methods of {{CassandraConnection}} by making them package {{protected}}.
> 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
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Rick Shaw (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (CASSANDRA-3091) Move the caching of KS and CF
metadata in the JDBC suite from Connection to Statement
Posted by "Rick Shaw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Shaw updated CASSANDRA-3091:
---------------------------------
Attachment: move-metadata-for decoder-to-statement-level-v1.txt
> 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
>
>
> 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
[jira] [Issue Comment Edited] (CASSANDRA-3091) Move the caching of
KS and CF metadata in the JDBC suite from Connection to Statement
Posted by "Rick Shaw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092862#comment-13092862 ]
Rick Shaw edited comment on CASSANDRA-3091 at 8/29/11 2:38 PM:
---------------------------------------------------------------
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.
Note in JDBC it is the {{Statement}} that is used to execute commands, not {{Connection}}.
was (Author: ardot):
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: 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