Hi,
My earlier question was whether it is safe to cache PreparedStatement
(using Java driver) in the client side for which I got it confirmed by
Olivier.
Now the question is do we really need to cache the PreparedStatement in the
client side?.
Lets take a scenario as below:
1) Client fires a REST query "SELECT * from Test where Pk = val1";
2) REST service prepares a statement "SELECT * from Test where Pk = ?"
3) Executes the PreparedStatement by setting the values.
4) Assume we don't cache the PreparedStatement
5) Client fires another REST query "SELECT * from Test where Pk = val2";
6) REST service prepares a statement "SELECT * from Test where Pk = ?"
7) Executes the PreparedStatement by setting the values.
In this case, is there any benefit of using the PreparedStatement?
From the Java driver code, the Session.prepare(query) doesn't check
whether a similar query was prepared earlier or not. It directly call the
server passing the query. The return from the server is a PreparedId. Do
the server maintains a cache of Prepared queries or it still perform the
all the steps to prepare a query if the client calls to prepare the same
query more than once (using the same Session and Cluster instance which I
think doesn't matter)?.
Thanks
Ajay
On Sat, Feb 28, 2015 at 9:17 AM, Ajay <ajay.ga...@gmail.com> wrote:
> Thanks Olivier.
>
> Most of the REST query calls would come from other applications to
> write/read to/from Cassandra which means most queries from an application
> would be same (same column families but different values).
>
> Thanks
> Ajay
> On 28-Feb-2015 6:05 am, "Olivier Michallat" <
> olivier.michal...@datastax.com> wrote:
>
>> Hi Ajay,
>>
>> Yes, it is safe to hold a reference to PreparedStatement instances in
>> your client code. If you always run the same pre-defined statements, you
>> can store them as fields in your resource classes.
>>
>> If your statements are dynamically generated (for example, inserting
>> different subsets of the columns depending on what was provided in the REST
>> payload), your caching approach is valid. When you evict a
>> PreparedStatement from your cache, the driver will also remove the
>> corresponding id from its internal cache. If you re-prepare it later it
>> might still be in the Cassandra-side cache, but that is not a problem.
>>
>> One caveat: you should be reasonably confident that your prepared
>> statements will be reused. If your query strings are always different,
>> preparing will bring no advantage.
>>
>> --
>>
>> Olivier Michallat
>>
>> Driver & tools engineer, DataStax
>>
>> On Fri, Feb 27, 2015 at 7:04 PM, Ajay <ajay.ga...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> We are building REST APIs for Cassandra using the Cassandra Java Driver.
>>>
>>> So as per the below guidlines from the documentation, we are caching the
>>> Cluster instance (per cluster) and the Session instance (per keyspace) as
>>> they are multi thread safe.
>>>
>>> http://www.datastax.com/documentation/developer/java-driver/2.0/java-driver/fourSimpleRules.html
>>>
>>> As the Cluster and Session instance(s) are cached in the application
>>> already and also as the PreparedStatement provide better performance, we
>>> thought to build the PreparedStatement for REST query implicitly (as REST
>>> calls are stateless) and cache the PreparedStatemen. Whenever a REST query
>>> is invoked, we look for a PreparedStatement in the cache and create and put
>>> it in the cache if it doesn't exists. (The cache is a in-memory fixed size
>>> LRU based).
>>>
>>> Is a safe approach to cache PreparedStatement in the client side?.
>>> Looking at the Java driver code, the Cluster class stores the
>>> PreparedStatements as a weak reference (to rebuild when a node is down or
>>> a new node added).
>>>
>>> Thanks
>>> Ajay
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to java-driver-user+unsubscr...@lists.datastax.com.
>>>
>>
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to java-driver-user+unsubscr...@lists.datastax.com.
>>
>
