tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morten Jorgensen <morten.jorgen...@openjawtech.com>
Subject Re: Who wants my Cassandra session manager for Tomcat?
Date Wed, 04 Apr 2012 16:18:39 GMT
Thanks again for your comments. More replies below:
>>> 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?
Good question. For large web applications, and particularly web-based 
UIs with multiple
user screens, you would have certain data in your session for the 
various screens/pages.
Not all pages need _all_ data in your session, and since the session 
manager loads session
attributes only when the web app code asks for it, only the data that is 
required for the
current page is loaded from Cassandra.
>
>> 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?
The session manager works without this cache, but is slow. The cache is 
configured
as a filter configured in web.xml. The code of a web app won't have to 
be changed,
but you need to update your web.xml to use the session manager effectively.
> * is that even a word?
Yes it is, according to dictionary.com
>
>> 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.
Cassandra allows you choose your consistency level. I use a quorum 
write, which
writes to (N/2)+1 Cassandra nodes, where the Cassandra ring contains N 
nodes.
I think this makes sense for web session data, and my current implementation
has this consistency-level hard-coded. I think it would probably make 
sense to
allow this to be configured.
>
>> 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.
I don't think there is a clean way of doing this without overriding the 
default Map
implementations of the JVM. But, I think storing session data as 
individual session
attributes rather than large object hierarchies is good (but not common)
programming practice. It allows the session container/manager to manage
read/write operations of the session attributes separately. This 
practice should
benefit not only my Cassandra session manager but also the existing 
Delta 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?
For the cache? The main reason why I use a filter is to be able to tie a 
cache
object to a thread-local variable for the period for which the request 
is being
processed. As soon as the response is streamed to the client the cache 
is released.
If Tomcat already contains some internal reference to the current 
request then I
won't need to use a filter in this manner. I am not a fan of 
thread-local variables,
so I'd very much like to remove the dependency on having this filter in 
place.

Morten

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message