-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas,
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 session. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1asX4ACgkQ9CaO5/Lv0PDaEwCZAX1Rm4r5Xi1OZE9tXozuYnnb 8cwAnRwg67yL9qjG2Zbwi6kryoD7XcX1 =c4Pg -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
