Best practice for managing different consistency levels using the Datastax Cassandra native java client

Question

Using CQL3, the Cassandra consistency level is now set at the session level. The Datastax documentation for the native Java client states:

Session instances are thread-safe and usually a single instance is all you need per application

But I struggle to see how a single Session instance can handle multiple consistency levels (for example writes with QUORUM and reads with ONE). I see potential race conditions all over the place.

An obvious solution would be to create separate sessions for reads and writes, each with the appropriate consistency level set. But this doesn't fully solve the problem. What if a class modified the consistency level for one of the two sessions? All subsequent users of the Session instance would then, unknowingly, be using the new CL.

So, as far as I can see, the safest option is to create a new Session instance each time Cassandra needs to be accessed, with the CL explicitly set upon creation.

What is not clear to me is whether this approach would entail a performance penalty. For example, would either session = cluster.connect() or session.execute("CONSISTENCY [cl]") involve a trip to the server?

Am I missing something here? Has anybody got any relevant experience to share? Thanks.

UPDATE: I see com.datastax.driver.core.Query has a method for setting the consistency level. So perhaps the simplest option is stick with a single Session instance and set the CL for each query.

Answer 1

So perhaps the simplest option is stick with a single Session instance and set the CL for each query.

Not only is that the simplest option, it is the option.

In version 1.0.2 of the driver there was no way to set the consistency level anywhere else that per-query. There was no per-Session CL. Since version 2.0 of the Java driver, the global default consistency level can be set for the Cluster through the Cluster.Builder.withQueryOptions() method.

Though, for what is worth, my personal opinion is that the CL is an important parameter of each query. So I wouldn't find it crazy to set it for each query even when it's to keep the default of ONE for documentation sake (i.e. to say "I do have though about what is the relevant CL for this query and it's ONE").