incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Robson <mar...@gmail.com>
Subject Re: random n00b question
Date Tue, 15 Sep 2009 15:09:39 GMT
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

Mime
View raw message