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 <email@example.com>
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..