Caching prepared queries and different consistency levels

[Wayne Schroeder <ws...@pinsightmedia.com>]

After upgrading to the 2.0 driver branch, I received a lot of warnings about re-preparing previously prepared statements.  I read about this issue, and my work around was to cache my prepared statements in a Map<String, PreparedStatement> internally in my app via a common prepare method, where the string key was the CQL query itself.  This has been working perfectly, but I realized today that the consistency level I was setting on BoundStatement is actually inherited from Statement.  Now, while it is obviously not the same object instance (the BoundStatement vs the cached PreparedStatement), I was concerned that I was inadvertently changing the consistency level of the cached PreparedStatement in a non thread safe fashion.  My impression had been that the BoundStatement, even though created against a cached/shared PreparedStatement, was mine to do with what I pleased exclusively in my thread context.  Is this a correct/incorrect assumption?

I guess what it boils down to is the following:   Are the consistency level in the PreparedStatement and BoundStatement linked when the BoundStatement is created so that modifying the consistency level of the BoundStatement modifies the underlying PreparedStatement?

What I am hoping is the case is that the PreparedStatement's consistency level is just used to initialize the BoundStatement and that the BoundStatement's consistency level is then used when executing the query.

Wayne

Re: Caching prepared queries and different consistency levels

[Wayne Schroeder <ws...@pinsightmedia.com>]

Well, it may seem like I'm talking to myself now with this response, but I cracked open the source and found the answer in fairly short order so I figured I would share what I found.  Datastax folks, please do verify that I'm correct if you don't mind.

Long story short, BoundStatement initializes from the PreparedStatement's consistency, and that's where it stops -- it is not connected to the original PreparedStatement.  The thing I have to be careful about is changing the consistency level of the PreparedStatement's that I am caching as it will effectively change the default of ONE that I am expecting.  This is obviously specific to my application, but hopefully it helps anyone who has followed that pattern as well.

Wayne


On Feb 28, 2014, at 12:18 PM, Wayne Schroeder <ws...@pinsightmedia.com>
 wrote:

> After upgrading to the 2.0 driver branch, I received a lot of warnings about re-preparing previously prepared statements.  I read about this issue, and my work around was to cache my prepared statements in a Map<String, PreparedStatement> internally in my app via a common prepare method, where the string key was the CQL query itself.  This has been working perfectly, but I realized today that the consistency level I was setting on BoundStatement is actually inherited from Statement.  Now, while it is obviously not the same object instance (the BoundStatement vs the cached PreparedStatement), I was concerned that I was inadvertently changing the consistency level of the cached PreparedStatement in a non thread safe fashion.  My impression had been that the BoundStatement, even though created against a cached/shared PreparedStatement, was mine to do with what I pleased exclusively in my thread context.  Is this a correct/incorrect assumption?
> 
> I guess what it boils down to is the following:   Are the consistency level in the PreparedStatement and BoundStatement linked when the BoundStatement is created so that modifying the consistency level of the BoundStatement modifies the underlying PreparedStatement?
> 
> What I am hoping is the case is that the PreparedStatement's consistency level is just used to initialize the BoundStatement and that the BoundStatement's consistency level is then used when executing the query.
> 
> Wayne
>