"Quinton McCombs" <[EMAIL PROTECTED]> writes: > > -----Original Message----- > > From: Daniel Rall [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, February 04, 2003 4:50 PM > > To: Quinton McCombs > > Cc: [EMAIL PROTECTED] > > Subject: RE: TurbineSessionService > > > > > > 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. > > I don't think that we should remove it from the list. It is still a > user's session even though it has been passivated. I do think that it > shgould be treated differently though. In this case, the actual session > object used by the container could be subject to garbage collection.
I agree with you, but am not certain how to distinguish between passivation as a result of servlet container shutdown and other types of passivation. If we ignore passivation (e.g. let the sessionDidPassivate(HttpSessionEvent) callback be a no-op), how can we properly handle activation? The same catch-22 seems to apply... > > > 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. > > I agree with the changes that you have made. I do wonder what will > happen when a session object is used by the session service (to > invalidate it) while it is passivated. I would hope that the container > will reactivate it instead of throwing an Exception. I am not sure what will happen with Tomcat, and the actual behavior is likely container-dependent. Perhaps we need some exception handling code which catchs Throwable? -- Daniel Rall <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
