Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D141B10E14 for ; Wed, 12 Mar 2014 23:53:38 +0000 (UTC) Received: (qmail 80376 invoked by uid 500); 12 Mar 2014 23:53:36 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 80298 invoked by uid 500); 12 Mar 2014 23:53:35 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 80290 invoked by uid 99); 12 Mar 2014 23:53:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Mar 2014 23:53:35 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of apopescu@datastax.com designates 209.85.223.177 as permitted sender) Received: from [209.85.223.177] (HELO mail-ie0-f177.google.com) (209.85.223.177) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Mar 2014 23:53:29 +0000 Received: by mail-ie0-f177.google.com with SMTP id rl12so229505iec.36 for ; Wed, 12 Mar 2014 16:53:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=/k7sQX6kOn3/t8da4aHraDg2saVixsZzz/dUK4qah08=; b=QimuDeQJH37/jcJClrB2oyeFMhBbUywfeB199T9+y9FS+6CI2LCiWpmUT5pRr+fa/D DHtdrD8v47Sym91U/E0ENVf3z8icmAlxtAA7sEdvPJDbFRiQP3X1PhrWi52bQCzmOVeY LWlkdHxhUibrhnRyjTbB4yNxy/Pzhz7R8/HxhUafvX8oVhZeTPQZqF3oL1YJIcomRLiy wr5qjqlu6BbwbRA5BoLvTSxkRgf9XpefA4Sog25MA62DCDvlQfu6gxs/x3qFPU8Ttvfx H9zMzuaHV5Jo8G+dDWNgg5tbnxTgXYQCMc6fU3vrui2RnsWAbJZbHotDIEJoN7RBEWtL QeMw== X-Gm-Message-State: ALoCoQm6W8TWcfVrML6WGi7TGNAeeUR3cfLXHe7FZ1eXGk90YRwwn8IpXO2EPNqeXoJYwtiJ2Gs+ X-Received: by 10.50.3.98 with SMTP id b2mr957783igb.23.1394668387619; Wed, 12 Mar 2014 16:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.170.34 with HTTP; Wed, 12 Mar 2014 16:52:47 -0700 (PDT) In-Reply-To: <9FD9C2860A087F4398EB3FB01F19AA5F6934F30E@G4W3292.americas.hpqcorp.net> References: <9FD9C2860A087F4398EB3FB01F19AA5F6934F30E@G4W3292.americas.hpqcorp.net> From: Alex Popescu Date: Wed, 12 Mar 2014 16:52:47 -0700 Message-ID: Subject: Re: Driver documentation questions To: user Content-Type: multipart/alternative; boundary=089e01294648d3242b04f4718955 X-Virus-Checked: Checked by ClamAV on apache.org --089e01294648d3242b04f4718955 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-us= er On Fri, Mar 7, 2014 at 12:42 PM, Green, John M (HP Education) < john.green@hp.com> wrote: > I=E2=80=99ve been tinkering with both the C++ and Java drivers but in ne= ither > case have I got a good indication of how threading and resource mgmt shou= ld > 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=E2=80=99ve seen so far is for sing= le > threaded command-line applications so I=E2=80=99m wondering what is threa= d safe (if > anything) and what objects are =E2=80=9Cexpensive=E2=80=9D to instantiate= . I=E2=80=99m 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? Wh= at > about a builder? > > > > John =E2=80=9Clost in the abyss=E2=80=9D > --=20 :- a) Alex Popescu Sen. Product Manager @ DataStax @al3xandru --089e01294648d3242b04f4718955 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 Se= ssion per keyspace.=C2=A0

=C2=A0 =C2=A0 A session = manages connection pools =C2=A0for nodes in the cluster and it's an exp= ensive resource.

=C2=A0 =C2=A0 2.1. In case your application uses a lot = of keyspaces, then you should try to limit the number=C2=A0of 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) &l= t;john.green@hp.com<= /a>> wrote:

I=E2=80=99ve been tinkering with both the C++ and Ja= va drivers but in neither case have I got a good indication of how threadin= g and resource mgmt should be implemented in a long-lived multi-threaded ap= plication server process.=C2=A0=C2=A0=C2=A0 That is, what should be the scope of a builder, a cluster, session, and statement. =C2= =A0=C2=A0A JDBC connection is typically a per-thread affair.=C2=A0 =C2=A0= =C2=A0When application server receives a request, it typically

a)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gets JDBC connection from a connection pool,

b)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 processes the request

c)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 returns the connection to the JDBC connection pool.=

=C2=A0

All the Cassandra driver sample code I=E2=80=99ve se= en so far is for single threaded command-line applications so I=E2=80=99m w= ondering what is thread safe (if anything) and what objects are =E2=80=9Cex= pensive=E2=80=9D to instantiate.=C2=A0=C2=A0 I=E2=80=99m assuming a Session= is analogous to a JDBC connection so when a request comes into my multi-threaded applic= ation server, I should create a new Session (or find a way to pool Sessions= ), but should I be creating a new cluster first?=C2=A0=C2=A0 What about a b= uilder?

=C2=A0

John =E2=80=9Clost in the abyss=E2=80=9D




--

:- a)


Alex= Popescu
Sen. Product Manager @ DataStax
@al3xandru
--089e01294648d3242b04f4718955--