On Sep 15, 2009, at 8:09 AM, Mark Robson wrote:
Quorum read / write would be required, yes.
2009/9/15 Jonathan Ellis <email@example.com>
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.
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.