Hi, Is it not possible to access session attributes in the method sessionDestroyed() of HttpSessionListener by using the session object returned from HttpSessionEvent?? Shankar.
Marty Hall
Author
Ranch Hand
Joined: Jan 02, 2003
Posts: 111
posted
0
Is it not possible to access session attributes in the method sessionDestroyed() of HttpSessionListener by using the session object returned from HttpSessionEvent??
Correct; it is not possible. As discussed in Section 10.7 of More Servlets and JSP, the attributes are removed before sessionDestroyed is called. You need to catch them in the attributeRemoved method of HttpSessionAttributeListener. I haven't found much use for sessionDestroyed other than listeners that merely keep track of the number of active sessions (which is actually helpful to know). Cheers- - Marty
Java training and consulting<br /><a href="http://www.coreservlets.com/" target="_blank" rel="nofollow">http://www.coreservlets.com/</a>
shankar vembu
Ranch Hand
Joined: May 10, 2001
Posts: 309
posted
0
thanx marty, i found it the hard way. actually i had to reset the user login status in the database when session is destroyed. HttpSessionListener did not help me, i modified my design and now using HttpSessionBindingListener. This is clean and works perfect. Thanx for confirming... SHankar
It may depend upon which servlet container and version you are using. Under the Servlet 2.3 specification, the definition of the sessionDestroyed method was:
Notification that a session was invalidated.
under Servlet 2.4:
Notification that a session is about to be invalidated.
So it is perfectly plausible that a 2.3 engine would blow away the session prior to calling sessionDestroyed, while a 2.4 engine will not.
How do I get the actual session attribute object? I have a servlet that for various reasons needs to open a DB connection with each session, and I want to close those connections as the sessions time out. How do i get the actual Connection object that is the value of my session attribute, so I can call close() on it? Thanks, John
I agree. Here's the link: http://ej-technologies/jprofiler - if it wasn't for jprofiler, we would need to
run our stuff on 16 servers instead of 3.