2009/9/15 Jonathan Ellis <[email protected]> > 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
