tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Replicate session-object after values in object has been changed
Date Tue, 15 Feb 2011 17:01:51 GMT
Hash: SHA1


On 2/14/2011 2:44 PM, Thomas Andraschko wrote:
> Does other Servlet containers support this kind of replication or is
> it really the only way to put/remove the object to/from the session
> map?

I've been browsing the servlet spec and I can't find a place where it
says exactly what events trigger session attribute replication in a
distributed environment. It seems obvious that
HttpSession.removeAttribute and HttpSession.setAttribute (and
removeValue/putValue) should trigger a replication event, for example.

On the other hand, it's very difficult for a container to determine what
the definition of "changed" is. For instance, an object may return a
different value for a method call depending on the current date and
time, yet the internal state of the object hasn't actually changed. If
Tomcat simply called all the method that return values, remembered them
all, then did a comparison at the end of every request, you'd end up
with a whole bunch of needless replication messages flying around your
cluster. Also, remembering all those return values (and, potentially all
the return values of sub-objects) would roughly double the size of every

Another technique might be to serialize an object and check against
/that/ after every request. This also doubles the size of every session.

I suppose md5(serialize(object)) could work without doubling the size of
the objects.

All of these techniques will kill performance. :(

Containers probably choose not to implement anything like the above
because the semantics of a web application's objects are simply opaque
to the container and it doesn't make any sense to even try. It's simple
enough to trigger a replication event by doing:

session.setAttribute(key, session.getAttribute(key));

> It is possible to develop a valve or interceptor to check specified
> entries in the session map and replicate them again? (sorry, i don't
> know the architecture very well)

Tomcat supports both Valves and Filters. I would recommend a Filter
since it will be portable across containers should you choose to switch
at some point in the future.

I think as you start to implement such a feature, you'll begin to
understand why containers generally don't implement this kind of behavior.

I am very interested in how the memcache folks accomplish this. Martin:
is this done via careful configuration of what "changed" means or is
everything automatic?

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message