Submit queries with DataStax drivers

The ability to submit queries and receive results is the core functionality of DataStax drivers. For information about building queries, see your driver’s documentation:

Don’t create session objects for specific keyspaces. Instead, create one session object per application, and then explicitly set keyspaces on statement objects or use fully qualified keyspaces in your application’s query strings.

Synchronous and asynchronous query execution

DataStax drivers can execute queries against a database synchronously or asynchronously. The appropriate choice for your application depends on your use cases and requirements.

DataStax drivers execute queries synchronously by default, except for the Node.js driver, which supports only asynchronous query execution.

This means that the application sends a query to the database, and then the thread that sent the query waits for the query to complete before proceeding. In multi-threaded applications, other threads can continue to run while the query is processed. In single-threaded applications, this can block the entire application while waiting for the query result.

With synchronous query execution, it is easy to tell when a query completes, and this can make the application’s execution logic easier to follow.

However, each thread can only execute one query at a time. While server nodes usually take less than a millisecond to fulfill a request, throughput can degrade when executing extremely large numbers of queries or while waiting for long-running queries to finish. If your application needs to process thousands or millions of queries, asynchronous query execution can be more performant.

Set request timeouts

You can set a request timeout for each CQL statement.

To determine the ideal timeout value, consider that each query execution can require multiple actions:

Default request execution with no retries or additional handling.
Sending requests to multiple nodes if the initial attempt fails (retries).
Scheduling and executing speculative retries.
Establishing new node connections if other connections are already executing the maximum number of concurrent requests.
Repreparing CQL statements if a prepared statement ID wasn’t found on the server.
Executing custom RequestTracker implementations, if applicable to the driver.

Additionally, DataStax recommends higher timeouts for DDL statements because they can take longer to execute. For example, in Apache Cassandra® 5.0 and later, DDL statements are executed sequentially.

C/C++ driver statement timeouts

See CassStatement and Execution profiles.

C# driver statement timeouts

You can set timeouts in the Session.Execute() and Session.ExecuteAsync() methods. For more information, see C# driver statements and Execution profiles.

GoCQL driver statement timeouts

See ClusterConfig.Timeout and Execution profiles.

Java driver statement timeouts

The timeout declared on the CQL statement is the global timeout for execution of the query.

You can also set timeouts in execution profiles.

Node.js driver statement timeouts

See ExecutionOptions and Execution profiles.

Python driver statement timeouts

You can set query timeouts in session.execute().

rows = session.execute("CREATE TABLE cycling.race_winners (
   race_name text,
   race_position int,
   cyclist_name FROZEN<fullname>,
   PRIMARY KEY (race_name, race_position));
", timeout=10)

You can also set timeouts in execution profiles.

Ruby driver statement timeouts

You can set query timeouts in session.execute and Execution profiles.

Submit queries with DataStax drivers

Synchronous and asynchronous query execution

Set request timeouts

See also

Was this helpful?

Give Feedback