Cassandra Java Driver Session

Cassandra Java Driver Session

In this blog post, we will discuss the different session classes available in the Cassandra Java driver. A session is meant to handle the execution of certain types of commands on a Cassandra cluster. Different types of sessions are meant to handle different types of interactions. Sessions can also configure the way that they connect to a Cassandra cluster, manipulating where interactions are sent for processing.


The original Session is a Java interface (a sort of incomplete class definition) is com.datastax.driver.core. The documentation describes Session as:

“A session holds connections to a Cassandra cluster, allowing it to be queried.

Each session maintains multiple connections to the cluster nodes, provides policies to choose which node to use for each query (round-robin on all nodes of the cluster by default), and handles retries for failed queries (when it makes sense), etc…

Session instances are thread-safe and usually a single instance is enough per application. As a given session can only be “logged” into one keyspace at a time (where the “logged” keyspace is the one used by queries that don’t explicitly use a fully qualified table name), it can make sense to create one session per keyspace used. This is however not necessary when querying multiple keyspaces since it is always possible to use a single session with fully qualified table names in queries.”

The Session interface sets up for a number of methods, including the prepare() and execute(). Those methods are used in a number of Cassandra drivers. Prepare is where CQL statements and the like can be prepared with boilerplate and syntax. Those statements are then filled in later for execution. Execute uses the object’s parameters to send a command to a Cassandra cluster. Session code can be found here.


CqlSession is part of the Cassandra Java Driver for Apache Cassandra. It is a specialized version meant to easily execute CQL statements. CqlSession differs from the original interface because it has different preparation and execution statements. Those new methods are meant to process different types of objects. Either a specific type of Statement object built specifically for CQL statements or string objects conforming to CQL statement rules. The code for can be found here.


DseSession is an extension of Session that adds DSE-specific features to the interface. Alongside the prepare and execute methods for interacting with Cassandra via CQL, DseSession also includes executeGraph() methods for interacting with DSE Graph through the driver. The driver then takes queries based on the Gremlin graph query language. The code for can be found here.


Cassandra.Link is a knowledge base that we created for all things Apache Cassandra. Our goal with Cassandra.Link was to not only fill the gap of Planet Cassandra but to bring the Cassandra community together. Feel free to reach out if you wish to collaborate with us on this project in any capacity.

We are a technology company that specializes in building business platforms. If you have any questions about the tools discussed in this post or about any of our services, feel free to send us an email!