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

Question

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

Session instances are thread safe and typically only one instance is required for each application

But I'm struggling to understand how a single instance of a session can handle several levels of consistency (for example, it writes with QUORUM and reads with ONE). I see potential race conditions everywhere.

The obvious solution would be to create separate read and write sessions, each of which has an appropriate level of consistency. But this does not completely solve the problem. What if the class has changed the level of consistency for one of two sessions? All subsequent users of the session instance could then, unconsciously, use the new CL.

So, as far as I can tell, the safest option is to create a new instance of the session every time Cassandra should be available and CL is explicitly set to create.

What I don’t understand is whether such an approach would entail a performance penalty. For example, will session = cluster.connect() or session.execute("CONSISTENCY [cl]") include a trip to the server?

Am I missing something? Has anyone got any relevant experience? Thanks.

UPDATE: I see that com.datastax.driver.core.Query has a method for setting the level of consistency. Therefore, perhaps the easiest option is to use one instance of the session and set the CL for each request.

Answer 1

So, perhaps the easiest option is to use one instance of the session and set the CL for each request.

Not only is this the easiest option, but also an option.

In version 1.0.2 of the driver, there was no way to establish the level of consistency anywhere else that the request was. There was no CL for each session. Starting with version 2.0 of the Java driver, you can set the default global consistency level for a cluster using the Cluster.Builder.withQueryOptions() method.

Although, for what it's worth, my personal opinion is that CL is an important parameter of every request. Therefore, I would not have thought it crazy to set it for each request, even if it would support the ONE default for documentation (i.e. say "I have at least what is the corresponding CL for this request, and this is ONE").