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
instance
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.
[1]
https://groups.google.com/a/lists.datastax.com/forum/#!forum/java-driver-user
On Fri, Mar 7, 2014 at 12:42 PM, Green, John M (HP Education) <
john.gr...@hp.com> 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
@al3xandru
