On Tue, 4 Feb 2003, Quinton McCombs wrote: > 1) The container passivates and reactivates the session. This could be > to conserve memory or any other reason except restarting the container.
Iteresting observation -- I haven't used a container configured to do this. For instance, Tomcat 4.1.18's StandardManager only passivates sessions when its unload() method is called (on shutdown, for instance). I see that its PersistentManagerBase passivates sessions if there are too many active or they are idle for too long (processMaxIdleSwaps() and processMaxActiveSwaps(), respectively), but this does remove the sessions from its list of active sessions. Should this also remove them from Turbine's list of active sessions? I'm not sure. > Here, we will still have a reference to the session object. I am not > sure if we will have just a copy or a reference to the container's > object. Either way, the problem is almost the same. After it has been > reactivated, the session service will have a different HttpSession > object than the one cached by TurbineSessionService. The actual Java object acquired on reactivation doesn't seem relevant. So long as the session object represents the same actual data, the container is free to do as it wishes with the session objects (for instance, Tomcat 4.1.18 facades its interal Session implementations). The data structure used by TurbineSessionService to store its list of active sessions is keyed by session ID, which should be the same after session re-activation. > 2) The container passivates the session on shutdown and activates on the > next startup. > > At least in this case, it is MUCH easier to figure out where the problem > is coming from. I agree that container probabley would not call > sessionCreated() on our interface. The only way that we would be able > to get this back into our working list is by implementing the > HttpSessionActivationListener interface. Agreed. I checked the source of Tomcat, and none of its bundled Manager implementations call sessionCreated() in this fashion. > Now the question is how to implement the interface.... I think it will > be very straight forward except for handling the passivated sessions in > case #1. Thanks for your thoughts. Let me know what you think about the SessionListener changes I've made, and if you see any gotchas. - Dan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
