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,
Morten
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: www.openjawtech.com <http://www.openjawtech.com/>
Join OpenJaw Technologies Group on LinkedIn
<http://www.linkedin.com/groups?about=&gid=4074413> / Follow OpenJawTech
on Twitter <http://twitter.com/#%21/OpenJawTech>.
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
confidential.
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: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
