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.
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
Cassandra.
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
manager.
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.
Morten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
