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=15894>. 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=15894 Access to other sessions possible (session is immediately recycled after invalidation/expiration) [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From [EMAIL PROTECTED] 2003-01-14 17:22 ------- Hello William, Thanks for your fast reaction to my error report. I especially like that you use two states now for EXPIRED and INVALID. You fixed my problem by checking in request.getSession whether the session has still the same sessionId. This works if the servlet/JSP uses request.getSession before it uses the session. However, if you remove the line with s = request.getSession(true); (the one after sleep(5000); of my the example JSP you still get the same mistake. That why reopened the bug again. This problem is not just theoretical. The problem occurs when the client klicks many times without waiting for the server to deliver the page. If a normal request and a log-off request is processed simultaneous, the normal request will always read and write into the session of somebody else who logged in meantime. I see four solutions to this problem: 1. we delay the state change from EXPIRED to INVALID. With delay I mean to wait couple (e.g. 60) seconds. The state change from EXPIRED to INVALID could be either done by the Expirer or elsewhere. 2. we check on every access from HttpSessionFacade to ServerSession that we still have the right session as you did in request.getSession. We could do it in HttpSessionFacade.checkValid() for those methods who call it. 3. we register the HttpSessionFacade as listener for state change of the session. When the session gets expired we delete the reference session. We would have to check on session != null every time we use it. 4. We set session to null in HttpSessionFacade.invalidate. The rest is like (3). The problem here is that it only works if the session is invalidated through HttpSessionFacade.invalidate, but this should be ok. If you need my help for any solution, please let me know. Do you know by chance, how soon tomcat 3.3.2 will be released? Thanks a lot, Christian -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
