On Fri, 18 Oct 2002, Nick Sharples wrote:
> Date: Fri, 18 Oct 2002 09:45:32 +0100 > From: Nick Sharples <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: RE: Subclassing the Session object > > > 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. > An application cannot (itself) subclass the container-provided HttpSession implementation class. Therefore, a couple of different strategies seem feasible for this: * Modify Tomcat itself to do the replication for you, transparent to the application. * Make the application objects that you store in the session wrappers around the actual data, with enough smarts to refresh themselves as necessary. > ..Nick > Craig -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
