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



2009/9/15 Jonathan Ellis <jbellis@gmail.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.

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:

BEGIN TRANSACTION;
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';
COMMIT;


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