If your sessions are fairly long-lived (more like hours instead of minutes) and you crank up a suitable row cache and make sure your db is consistent (via quorum read/writes or write:all, read:1) - sure, why not?  Especially if you're already familiar with Cassandra; possibly even have a deployed instance already for your web app. Adding new components to the mix is always a sure way to get some headscratching going. For a small team who does not want to spend too much time on configuring yet another database, Cassandra would probably work well as a session store. And you would get cross-datacenter reliability too.

However, you might want to use 0.7 and expiring columns; otherwise cleaning up is going to be boring.


On Feb 1, 2011, at 22:24 , Sasha Dolgy wrote:

What I'm still unclear about, and where I think this is suitable, is Cassandra being used as a data warehouse for current and past sessions tied to a user.  Yes, other things are great for session management, but I want to provide near real time session information to my users ... quick and simple and i want to use cassandra ... surely i can't be that bad for thinking this is a good idea?

On Tue, Feb 1, 2011 at 9:20 PM, Kallin Nagelberg <kallin.nagelberg@gmail.com> wrote:
nvm on the persistence, it seems like it does support it:

'Since version 1.1 the safer alternative is an append-only file (a
journal) that is written as operations modifying the dataset in memory
are processed. Redis is able to rewrite the append-only file in the
background in order to avoid an indefinite growth of the journal.'

This thread probably shouldn't digress too much from Cassandra's
suitability for session management though..