DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18044>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18044 Session object recycling before all bound listeners has been notified. Summary: Session object recycling before all bound listeners has been notified. Product: Tomcat 3 Version: 3.1.1 Final Platform: Sun URL: www.flexstornet.com OS/Version: Solaris Status: NEW Severity: Critical Priority: Other Component: Servlet AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We have found severe problems in our application due to data being crossed from one session to another. This was reported while an user was attempting to log out and another user was attempting to log in. We store user credentials and other application information in the session context and have a session manager class implementing the HttpSessionBindingListener interface also stored in the session context. When the session is invalidated during voluntary user log out or by session timeout, our session manager gets notified and takes care of some duties like logging a log out transaction to the database. We have found that when the access to the database take some time (which makes the processing in the valueUnbound method to take some time), a new user logging in will be assigned a new session id but apparently a recycled HttpSession object belonging to the user logging out and still containing attribute that have not been removed. We have been able to reproduce and verify this problem very easily, by bounding an object from a class that implements this code in the valueUnbound method: public void valueUnbound( HttpSessionBindingEvent event ) { // trace 1 System.out.println( "Session Manager Thread sleeping for session " + event.getSession().getId() ); try { Thread.sleep( 120000 ); } catch ( InterruptedException ex ) {} // trace 2 System.out.println( "Session Manager Thread resuming for session " + event.getSession().getId() + " ..." ); } When the session is invalidated and this attribute object gets notified, it will print out the session id (trace 1) and sleep for 2 minutes. In the meantime, another session being requested which will be assigned a new session id but recycling the HttpSession object. When the thread wakes up, it will print the new session id (trace 2) which has been rewritten in the object. We have tested exactly the same testing code and our application in Tomcat 4.1.18 and everything works fine. Tomcat 3.3.1 final and 3.3.1a present the same problem. We think, that the recycling mechanism is invalidating the session, and adding the session object to some recycling pool before all the attributes(listeners) implementing the HttpSessionBindingListener interface has been notified not giving them a chance to finish the proper session cleaning. Any help with this problem will be greatly appreciated. Best Regards, --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
