tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Who wants my Cassandra session manager for Tomcat?
Date Thu, 05 Apr 2012 00:02:01 GMT
Pid,

On 4/4/12 6:46 AM, Pid wrote:
> On 03/04/2012 22:18, Morten Jorgensen wrote:
>> Thanks to all for your feedback. I am providing some additional
>> information as requested:
>>> That's interesting.  Can you share some details about how it works?
>> Sure. It is quite simple. Cassandra is effectively a multi-level
>> distributed hash-map, so it lends itself very well do storing session
>> attributes.
>>
>> The session manager maintains two column families (like tables), one to
>> hold session meta-data such as the last access timestamp, etc. and one
>> column family to hold session attributes. Storing or reading a session
>> attribute is simply a matter of writing it using the session ID as the
>> row ID, and the session attribute name as the column name, and the
>> session attribute value as the column value.
>>
>> Session attributes are read and written independently, so the entire web
>> session does not have to be loaded into memory - only the session
>> attributes that are actually required to service a request are read.
>> This greatly reduces the memory footprint of the web applications that I
>> am developing for my employer.
> 
> I'd be concerned about how chatty that was.
> 
> Devil's advocate question: why store data in the session if it's not needed?

Honestly, I was thinking the same thing today: usually, non-memory-based
data management is usually done in such a way as to be completely
divorced from the HttpSession concept, anyway. One needs to use
HttpSession for things like unique ids being assigned to clients, etc.
but then everything else can be done completely separately from that.

There's no reason that a "CassandraSessionManager" would really need to
exist unless you wanted to have completely seamless Cassandra-based
storage. I would argue that you don't actually want that, since you have
to put so much plumbing code in that you end up being a slave to
HttpSession when what you really want to do is store binary data (since
that's all Cassandra *can* store) and have it bound to some unique
identifier (coincidentally the HttpSession id).

I almost think that a Map implementation (with associated identifier,
which could be session-id-based) with a Cassandra backing-store would be
more useful since you could use it in any container and even entirely
outside a container.

I'm starting to be more like +0 to this idea.

-chris


Mime
View raw message