cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Popescu <>
Subject Re: Driver documentation questions
Date Wed, 12 Mar 2014 23:52:47 GMT
While this is a question that would fit better on the Java driver group
[1], I'll try to provide a very short answer:

1. Cluster is an long-lived object and the application should have only 1
2. Session is also a long-lived object and you should try to have 1 Session
per keyspace.

    A session manages connection pools  for nodes in the cluster and it's
an expensive resource.

    2.1. In case your application uses a lot of keyspaces, then you should
try to limit the number of Sessions and use fully qualified identifiers

3. PreparedStatements should be prepared only once.

Session and PreparedStatements are thread-safe and should be shared across
your app.


On Fri, Mar 7, 2014 at 12:42 PM, Green, John M (HP Education) <> wrote:

>  I’ve been tinkering with both the C++ and Java drivers but in neither
> case have I got a good indication of how threading and resource mgmt should
> be implemented in a long-lived multi-threaded application server
> process.    That is, what should be the scope of a builder, a cluster,
> session, and statement.   A JDBC connection is typically a per-thread
> affair.    When application server receives a request, it typically
> a)      gets JDBC connection from a connection pool,
> b)      processes the request
> c)       returns the connection to the JDBC connection pool.
> All the Cassandra driver sample code I’ve seen so far is for single
> threaded command-line applications so I’m wondering what is thread safe (if
> anything) and what objects are “expensive” to instantiate.   I’m assuming a
> Session is analogous to a JDBC connection so when a request comes into my
> multi-threaded application server, I should create a new Session (or find a
> way to pool Sessions), but should I be creating a new cluster first?   What
> about a builder?
> John “lost in the abyss”


:- a)

Alex Popescu
Sen. Product Manager @ DataStax

View raw message