cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Goffinet <>
Subject Re: random n00b question
Date Tue, 15 Sep 2009 16:26:10 GMT

On Sep 15, 2009, at 8:09 AM, Mark Robson wrote:

> 2009/9/15 Jonathan Ellis <>
> We don't currently have any optimizations to provide "lightweight"
> session consistency (see #132), but if you do quorum reads + quorum
> writes then you are guaranteed to read the most recent write which
> should be fine for most apps.
> Quorum read / write would be required, yes.
> But the typical model used by web page session handlers also  
> requires locking, otherwise you can lose data by concurrent updates.

Do you really expect a user to open up multiple tabs and start  
clicking concurrently? Is the use case for bots? Remember, if you're  
trying to capture a user's activity and think they might open up many  
windows, I wouldn't be saving that into a session in general.

> Consider the read / modify / write scenario typically used, a  
> traditional database might do:
> SELECT sessiondata FROM sessions WHERE id='my session id' FOR UPDATE;
> ... with session in place, execute the page code, modifying  
> sessiondata in memory
> UPDATE sessions SET sessiondata='modified session data' WHERE id='my  
> session id';

That's doable. But in best practice, just a very bad idea. You're  
adding overhead to what your trying to accomplish. If you're sticking  
all your data into the session, that might just be a bad idea in  
general. I worked at company where the previous programmer tried to  
get very clever, and add memcache locks for sessions. Cleverness is  
almost always a _bad_ idea.

> Cassandra has no way to emulate this behaviour, therefore  
> functionality would be lost if you moved from a traditional database  
> session handler to Cassandra.
> Even using quorum reads and writes, if a user in the same session  
> has two pages active at once, session data would be trashed.
> Mark

View raw message