Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of edlinuxguru@gmail.com
 designates 209.85.161.44 as permitted sender)
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:content-transfer-encoding;
        b=ofq3pVAs6W7LGN+b7NsWs/uEz408bL7NaX/23Hkp9JG1XfwKJdjlTNWOOUSJq44CTd
         cloFVl9ze4O3py+6pPVn0EDrr26qNMKzoeWotownEX5rRdl2ermL+d6DmsS+9M3iy/3G
         kiLuhBSEIz6RIVg+5zvHhG/hmmoRAb9OkNlQw=
MIME-Version: 1.0
In-Reply-To: <AANLkTimRrOUdOQ+X2VuPwcAxkyqhRPN4adm0CxtC-2kt@mail.gmail.com>
References: <AANLkTinfBRBCCYLfUDJhg1sWmcxefJOFAT8UVqPQXPhC@mail.gmail.com>
	<1296582141589-5981961.post@n2.nabble.com>
	<F1ADABBBB05C564281981ED6717917D004205FAAB3@MAILCA6.rms.com>
	<AANLkTimRrOUdOQ+X2VuPwcAxkyqhRPN4adm0CxtC-2kt@mail.gmail.com>
Date: Tue, 1 Feb 2011 13:16:03 -0500
Message-ID: <AANLkTinghoXOOs+=2=RPv6sC_xqG1NcixS5Qn8q-PM9D@mail.gmail.com>
Subject: Re: cassandra as session store
From: Edward Capriolo <edlinuxguru@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 1, 2011 at 12:57 PM, Anthony John <chirayithaj@gmail.com> wrote=
:
> Not a concern - and here is why:-
> From the wiki arch section captioned below - eventual consistency does no=
t
> have to mean inconsistent reads. The concern is the overhead for consiste=
nt
> reads. But remember in the use case being cited, the expensive read will
> happen only during failover, not all the time.
>
> More specifically:=A0R=3Dread replica count=A0W=3Dwrite replica count=A0N=
=3Dreplication
> factor=A0Q=3DQUORUM=A0(Q =3D N / 2 + 1)
>
> If W + R > N, you will have consistency
>
> W=3D1, R=3DN
> W=3DN, R=3D1
> W=3DQ, R=3DQ where Q =3D N / 2 + 1
>
> On Tue, Feb 1, 2011 at 11:47 AM, Tong Zhu <Tong.Zhu@rms.com> wrote:
>>
>> The problem is where to store the session data. If the session need to b=
e
>> accessible by more than one web servers, the external storage is needed.
>>
>> Cassandra only supports eventual consistency. If web server w1 saves the
>> session at node 1 of cassendra while web server w2 retrieve the session =
from
>> different node, if these two requests are close enough, there is a chanc=
e
>> what w2 retrieved is different from what w1 saved. Is it a concern?
>>
>> Tong
>>
>>
>>
>> -----Original Message-----
>> From: buddhasystem [mailto:potekhin@bnl.gov]
>> Sent: Tuesday, February 01, 2011 9:42 AM
>> To: cassandra-user@incubator.apache.org
>> Subject: Re: cassandra as session store
>>
>>
>> Most if not all modern web application frameworks support sessions. This
>> applies to Django (with which I have most experience and also run it wit=
h
>> X.509 security layer) but also to Ruby on Rails and Pylons.
>>
>> So, why would you re-invent the wheel? Too messy. It's all out there for
>> you
>> to use.
>>
>> Regards,
>> Maxim
>>
>> --
>> View this message in context:
>> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/cassand=
ra-as-session-store-tp5981871p5981961.html
>> Sent from the cassandra-user@incubator.apache.org mailing list archive a=
t
>> Nabble.com.
>>
>>
>> This message and any attachments contain information that may be RMS Inc=
.
>> confidential and/or privileged. =A0If you are not the intended recipient=
 (or
>> authorized to receive for the intended recipient), and have received thi=
s
>> message in error, any use, disclosure or distribution is strictly
>> prohibited. =A0 If you have received this message in error, please notif=
y the
>> sender immediately by replying to the e-mail and permanently deleting th=
e
>> message from your computer and/or storage system.
>
>

Ah. Eventual Consistency! Mama no! RUN!

From:
Download JSR-000315 Java Servlet 3.0 Final Release for Documentation, Engli=
sh

Distributed Environments

Within an application marked as distributable, all requests that are
part of a session
must be handled by one JVM at a time. The container must be able to handle =
all
objects placed into instances of the HttpSession class using the setAttribu=
te or
putValue methods appropriately. The following restrictions are imposed to m=
eet
these conditions:

This look to be the responsibly of the web cluster to ensure
serialized access not the backend. (At least how I am reading it)