incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <>
Subject Re: cassandra as session store
Date Tue, 01 Feb 2011 18:16:03 GMT
On Tue, Feb 1, 2011 at 12:57 PM, Anthony John <> wrote:
> Not a concern - and here is why:-
> From the wiki arch section captioned below - eventual consistency does not
> have to mean inconsistent reads. The concern is the overhead for consistent
> reads. But remember in the use case being cited, the expensive read will
> happen only during failover, not all the time.
> More specifically: R=read replica count W=write replica count N=replication
> factor Q=QUORUM (Q = N / 2 + 1)
> If W + R > N, you will have consistency
> W=1, R=N
> W=N, R=1
> W=Q, R=Q where Q = N / 2 + 1
> On Tue, Feb 1, 2011 at 11:47 AM, Tong Zhu <> wrote:
>> The problem is where to store the session data. If the session need to be
>> 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 chance
>> what w2 retrieved is different from what w1 saved. Is it a concern?
>> Tong
>> -----Original Message-----
>> From: buddhasystem []
>> Sent: Tuesday, February 01, 2011 9:42 AM
>> To:
>> 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 with
>> 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:
>> Sent from the mailing list archive at
>> This message and any attachments contain information that may be RMS Inc.
>> confidential and/or privileged.  If you are not the intended recipient (or
>> authorized to receive for the intended recipient), and have received this
>> message in error, any use, disclosure or distribution is strictly
>> prohibited.   If you have received this message in error, please notify the
>> sender immediately by replying to the e-mail and permanently deleting the
>> message from your computer and/or storage system.

Ah. Eventual Consistency! Mama no! RUN!

Download JSR-000315 Java Servlet 3.0 Final Release for Documentation, English

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 setAttribute or
putValue methods appropriately. The following restrictions are imposed to meet
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)

View raw message