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, 03 Apr 2012 21:18:46 GMT
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 

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.

For improved performance I have added a write-through and a write-back 
cache, implemented as servlet filters. The cache is flushed or written 
back once the current request has finished processing. I am sure there 
is room for improvement here, as multiple concurrent requests for the 
same session should be served using the same cache instance.

The Manager does not maintain any references to Session instances at 
all, allowing them to be garbage collected at any time. This makes 
things very simple, as Cassandra holds all session state, and the 
session managers in my Tomcat nodes only act as a cache in front of 

The nature of Cassandra and the Tomcat's implementation of web sessions 
go together extremely well. I am surprised that nothing like this exists 
already. It is a square hole, square peg sort of scenario.

I also have an implementation of the Map interface that stores the 
values of each entry as a session attribute. The way many developers 
write web applications is to have a "session bean" (a session attribute) 
that contains a Map that maintains the actual session attributes. This 
is OK if the entire session is persisted as a whole, but it won't 
perform very well with the Cassandra session manager (or the Delta 
Session Manager from what I understand). A developer can replace their 
session bean's HashMap with the SessionMap utility, and the session 
attributes will be treated as proper session attributes by the session 
> 1. Be relatively self-contained -- i.e. not require much in the way of
> changes to existing classes
There are no changes to existing classes. My session manager implements 
the existing org.apache.catalina.Manager interface.
> 2. Not have any external dependencies (new JAR files, etc.). This might
> be a problem, depending on whether your code uses the REST API for
> Cassandra or a direct Java binding.
This could be a problem... I use the Hector API to access Cassandra, and 
there are about 10 JARs required for this API.
> 3. Include good documentation for how to set it up. See the existing
> session-persistence documentation for a guide, and aim to do a better job ;)
It is extremely easy to set up:
1) Configure your Cassandra ring (cluster).
2) Copy the required Hector API JARs and the Cassandra session manager 
JAR to tomcat/lib
3) Configure your web application descriptor to use the Cassandra 
session manager. Parameters in the web application descriptor point the 
session manager to one or more nodes in your Cassandra ring.
> 4. Include test cases and potentially instructions for setting-up a test
> environment (i.e. you're gonna need a working Cassandra instance).
This is pretty much non-existent right now, so I'll put some effort in 
there. What format do you guys use for your documentation? Do you still 
use docbook?

Thanks again for all your comments and feedback.


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

View raw message