Return-Path: Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org Received: (qmail 94353 invoked from network); 14 Jul 2009 13:34:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Jul 2009 13:34:13 -0000 Received: (qmail 48759 invoked by uid 500); 14 Jul 2009 13:34:22 -0000 Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org Received: (qmail 48748 invoked by uid 500); 14 Jul 2009 13:34:22 -0000 Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-user@incubator.apache.org Delivered-To: mailing list cassandra-user@incubator.apache.org Received: (qmail 48739 invoked by uid 99); 14 Jul 2009 13:34:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jul 2009 13:34:22 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of markxr@gmail.com designates 209.85.220.207 as permitted sender) Received: from [209.85.220.207] (HELO mail-fx0-f207.google.com) (209.85.220.207) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jul 2009 13:34:13 +0000 Received: by fxm3 with SMTP id 3so2894768fxm.12 for ; Tue, 14 Jul 2009 06:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=AX6V3NUXHH5yu0KZh0kRCLiducNwNbOvb0lwH3JBv5c=; b=tBgaUJSGIEiyUwvJveMFMrWEhnJ5tdCt+MYvr3VvDK6bmDpNldh/wahK3SO6ufGXtV OPaE6nsvgdjHgLU9PxR6ul2GbEW/eOeIdugKnSM8yIpp7ul7yYbih9GxUb7xzzTcEK8X OolTgrBoIUj2RjaKOuG8sk/cBVlNZkP4knhtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=PrW2YGmGs/qDl1evRfs6AXJ0XMLlbuGB14aWr365Dl6/xEl75+uTD2NOPj3WeryFXw Q5IQU2dIxplR7kj7/Dn7oT8f76+ysJ8/YixQBoMg329yPRq3TvOCS/78I6VZv6GnDXAA dlN3+OPZNb4lT1+mCJ67V2GCAFi/J8Y7uaaJ0= MIME-Version: 1.0 Received: by 10.204.117.142 with SMTP id r14mr6365062bkq.197.1247578432671; Tue, 14 Jul 2009 06:33:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Jul 2009 14:33:52 +0100 Message-ID: Subject: Re: Scaling from 1 to x (was: one server or more servers?) From: Mark Robson To: cassandra-user@incubator.apache.org Content-Type: multipart/alternative; boundary=0016e6da98f24f100d046eaa7d4d X-Virus-Checked: Checked by ClamAV on apache.org --0016e6da98f24f100d046eaa7d4d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/7/14 Johan Stuyts > One of the purposes I want to use Cassandra for is custom HTTP session > replication. Instead of storing the values in the session of the servlet > container I want to store them individually using unique keys in Cassandra. > I was hoping Cassandra would be fast enough for this. Fast enough - yes. Consistent enough - probably not. As it's a http session application, you really, really want writes to be visible from anywhere immediately. If you're using it for authentication (for example "keep me logged in for today" type function), then you'll need to get the absolute latest value from the session. The user will log on and expect to be logged on immediately, and be able to switch to different web servers transparently without being asked to log on again. Cassandra doesn't provide the guarantees about the latest changes being available from any given node, so you can't really use it in such an application. I don't know if the "blocking" variants of the write operations make any more guarantees, if they do then it might be suitable. Mark --0016e6da98f24f100d046eaa7d4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/7/14 Johan Stuyts <j.stuyts@zybber.nl>
One of the purposes I want to use Cassandra for is custom HTTP session repl= ication. Instead of storing the values in the session of the servlet contai= ner I want to store them individually using unique keys in Cassandra. I was= hoping Cassandra would be fast enough for this.

Fast enough - yes. Consistent enough - probably not.
As it's a http session application, you really, really want write= s to be visible from anywhere immediately. If you're using it for authe= ntication (for example "keep me logged in for today" type functio= n), then you'll need to get the absolute latest value from the session.=

The user will log on and expect to be logged on immediately, and be abl= e to switch to different web servers transparently without being asked to l= og on again.

Cassandra doesn't provide the guarantees about the = latest changes being available from any given node, so you can't really= use it in such an application.

I don't know if the "blocking" variants of the write oper= ations make any more guarantees, if they do then it might be suitable.
<= br>Mark
--0016e6da98f24f100d046eaa7d4d--