Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of goffinet@digg.com designates
 64.191.203.36 as permitted sender)
From: Chris Goffinet <goffinet@digg.com>
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: multipart/alternative; boundary=Apple-Mail-1--153135867
Subject: Re: random n00b question
Date: Tue, 15 Sep 2009 09:26:10 -0700
In-Reply-To: <ff1a07b80909150809u4cace1eei6137089d5a51390@mail.gmail.com>
To: cassandra-user@incubator.apache.org
References: <4AAE1581.90309@boboco.ie>
 <e06563880909140740rff2f9d6v68fb6e35ccd08028@mail.gmail.com>
 <7bfc6c610909141609k20f402c7o4419428916e8a642@mail.gmail.com>
 <FCDADA9E-A601-4CE3-BBB5-A2D44636A5D9@joestump.net>
 <7bfc6c610909141623k382b8302g1c6c9c9a8f9bfc2a@mail.gmail.com>
 <ff1a07b80909150317u6c5aaec9k768ec257f72952b1@mail.gmail.com>
 <4AAF6CCA.3030205@boboco.ie>
 <e06563880909150519q22f4e759wf86f915244d1e21e@mail.gmail.com>
 <ff1a07b80909150809u4cace1eei6137089d5a51390@mail.gmail.com>
Message-Id: <EB36A9D7-36D9-4B61-88FC-9A13569CEBE4@digg.com>


--Apple-Mail-1--153135867
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes


On Sep 15, 2009, at 8:09 AM, Mark Robson wrote:

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

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


--Apple-Mail-1--153135867
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 15, 2009, at 8:09 AM, Mark Robson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">2009/9/15 Jonathan Ellis <span dir="ltr">&lt;<a href="mailto:jbellis@gmail.com">jbellis@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We don't currently have any optimizations to provide "lightweight"<br>
session consistency (see #132), but if you do quorum reads + quorum<br>
writes then you are guaranteed to read the most recent write which<br>
should be fine for most apps.<br></blockquote><div><br></div></div>Quorum read / write would be required, yes.<br><br>But the typical model used by web page session handlers also requires locking, otherwise you can lose data by concurrent updates.<br>
<br></blockquote><div><br></div>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.&nbsp;</div><div><br><blockquote type="cite">Consider the read / modify / write scenario typically used, a traditional database might do:<br><br>BEGIN TRANSACTION;<br>SELECT sessiondata FROM sessions WHERE id='my session id' FOR UPDATE;<br>... with session in place, execute the page code, modifying sessiondata in memory<br>
UPDATE sessions SET sessiondata='modified session data' WHERE id='my session id';<br>COMMIT;<br><br></blockquote><div><br></div><div>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.</div><br><blockquote type="cite">Cassandra has no way to emulate this behaviour, therefore functionality would be lost if you moved from a traditional database session handler to Cassandra.<br>
<br>Even using quorum reads and writes, if a user in the same session has two pages active at once, session data would be trashed.<br><br>Mark<br>
</blockquote></div><br></body></html>
--Apple-Mail-1--153135867--