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.
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';
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.