Milt Epstein writes: > On Thu, 17 Oct 2002, Nick Sharples wrote: > > > > > Shapira, Yoav writes: > > > Hi, > > > I don't know the direct answer to your question. > > > > > > But I'm curious as to the use-case that's requiring you to subclass > > > HttpSession. As opposed to, for example, binding your (Serializable) > > > objects to the session? Thanks, > > > > We have a clustered environment and some legacy code that binds > > objects to the session. What I'd like to do, in order to avoid any > > rewritting, is sub-class the session object and intercept getAttribute > > calls so that changes made to the datamodel are reflected by any > > objects pulled off of the session. I'm sure I've seen this being done, > > but can't remember where you set it. > > Would HttpSessionBindingListener help with this?
Not in this case, unfortunately. > And do you mean setAttribute instead of getAttribute? The scenario goes something like this: An object is instantiated from information stored in a shared database and bound to a non replicated session. If another object is instantiated of the same class and with the same data (same object, different JVM) and changed on another machine in the cluster. Then, we'd want those changes to be propagated to all the other instantiated instances. If propagation doesn't take place the unchanged instances will over-write the changed database data. My first thoughts were to intercept the HttpSession.getAttribute calls with a refresh from the database first. ..Nick -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
