tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morten Jorgensen <>
Subject Re: Who wants my Cassandra session manager for Tomcat?
Date Tue, 10 Apr 2012 18:18:26 GMT
Chris, Pid & all,

I do see the argument for managing session-related data outside of the 
HttpSession, but for me this is an application development life-cycle 
issue. The applications that I manage has evolved over 8 years and has 
thousands of references to data stored in the HttpSession. The 
requirements for the applications have also evolved over the years. The 
traffic volumes for this off-the-shelf application is for some of our 
customers in the millions per day. I also need improved availability, 
resilience, failover and fault tolerance. I cannot simply replace all 
session data management (currently using HttpSession) across my entire 
applications, as the time/resources required to do this is massive. I 
need to be able to replace the foundation for my applications, while 
retaining as much of the applications as-is. Nor can I rely on the 
existing session managers in Tomcat, as these do not scale to meet the 
traffic volumes that my customers see in their environments.

I would imagine that there are several architects out there that are 
experiencing similar problems, hence I want to share my work.

The way caching is currently implemented is quick and dirty, and I agree 
that this should be done in a manner that does not require changes -to 
the existing web application (ref my development life-cycle requirements 
above). A request-scope write-back cache is not 100% reliable with 
multiple concurrent requests. A request-scope write-through cache is 
better (yet not 100% reliable as you can have stale data in the cache), 
but performance is not ideal. I will come up with a better solution for 
this, and I'll revert back to this list.

Thanks to all,

On 05/04/2012 01:02, Christopher Schultz wrote:
> 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


Morten Jørgensen
Chief Architect

*OpenJaw Technologies*
T: + 353 (0)1 - 882 5444
W: <>

Join OpenJaw Technologies Group on LinkedIn 
<> / Follow OpenJawTech 
on Twitter <>.

We have checked this material for computer viruses and although none has 
been found by us, we cannot guarantee that it is completely virus free 
and we do not accept any liability for loss or damage that may be 
caused. Please therefore check any attachments for viruses before using 
them on your own equipment. If you do find a computer virus please 
inform us immediately so that we may take appropriate action.

This communication is intended solely for the addressee and is 

If you are not the intended recipient, please delete this email. Any 
disclosure, copying, distribution or any action taken or omitted to be 
taken in reliance on it, is prohibited and may be unlawful.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message