The listener should get called only once, right? Whereas the filter will get called for every matching URL (keeping in mind it does additional useful things in my case...) and if checks to see if the session is new each and every time.
I seem to recall an issue recently (can't find it in a quick scan of the archives) about sessionDestroyed(SessionEvent) being called after the session is invalidated. I think the valueUnbound() method gets called during the destruction process and the session is still valid at this point. DON'T QUOTE ME ON THIS! I wrote the filter a while ago, and have just brought it along as needed... If someone knows for sure... Please let me (us) know. Tim -----Original Message----- From: David Kerber [mailto:[EMAIL PROTECTED] Sent: Thursday, February 09, 2006 1:16 PM To: Tomcat Users List Subject: Re: Logging session timeouts Thanks to both of you, Tim and Joey! I've tested them both, and either one of these methods seems to work great for my limited needs. I still have a question about performance: any idea which of these methods (filter or listener) will use less cpu time when handling 50 to 100 simultaneous users, each logged in with their own ID and session? Dave Tim Lucia wrote: >The filter, implementing HttpSessionListener, and binding itself to the >session, will be called by Tomcat when the session is invalidated (all >bound values which implement HttpSessionListener will have their >valueUnbound method called.) > >So, the filter is effective in that it won't miss any session unbind >events as long as the filter captures the creation request as well. If >you create the session but the request which does so has not passed >through the filter, then it will not know when the session goes away. > >So in the listener case, you are guaranteed a call from the server any >time any session is created. That might be a better approach, >depending on your need(s). In my case, the filter does a whole lot >more, but I stripped it down before posting it to only show the relevant section. > >Tim > >-----Original Message----- >From: Joey Geiger [mailto:[EMAIL PROTECTED] >Sent: Thursday, February 09, 2006 12:27 PM >To: 'Tomcat Users List' >Subject: RE: Logging session timeouts > >While the user can delete the cookie that is associated with the >session, the server will consider the session valid until it times out, >as the user is unable to end the session manually. If you add in a >link/button that says "Remove my session from server" and then have the >application invalidate the session, the listener would still log it the >same as if the server did it automatically, but you also now have control over logging that. > >I might be wrong (a famous saying) but I don't know how effective the >Filter version of the system will be, as it needs to be invoked via a >request in order to process/expire the session. The listener is able to >log sessions as they end, and not require a user to hit the filter >first. (If a user goes inactive, the session will expire, and the >listener will catch it and log >it) > > >-----Original Message----- >From: David Kerber [mailto:[EMAIL PROTECTED] >Sent: Thursday, February 09, 2006 11:09 AM >To: Tomcat Users List >Subject: Re: Logging session timeouts > >That got me going; thanks! > >One more question: >Is there any way of telling if the session was actively invalidated, or >if it timed out? Looking at the docs for HttpSessionBindingEvent, I >don't see any differentiation between them. That's not a big deal, but >would be nice to have. > >Dave > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
