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? > 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. But... (more devil's advocating, sorry) while this should address the chattiness* problem, doesn't it mean that your solution is invasive and can't be really deployed without modifying an app? * is that even a word? > 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'm not entirely sure I agree. Cassandra trades off consistency for availability and partition tolerance, whereas I'd suggest a session management solution would want to trade partition tolerance for consistency and availability. I'm also not sure that the comparison between column store and session attribute map stands up beyond the initial/apparent similarity between data type. Cassandra is write-optimised and hits disk (on at least two nodes for HA) for every write AFAIK. > 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. Is there not a way to do this internally & therefore transparently to the developer? Otherwise you're introducing more dependencies and creating more of a framework than a pluggable 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. Instead of the filter, could you use a Valve? p >> 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 > -- [key:62590808]
signature.asc
Description: OpenPGP digital signature
