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.

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;

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