On Sep 15, 2009, at 8:09 AM, Mark Robson wrote:
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.
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
