Bug 40305 - The getSession() method returns invalid session.
Summary: The getSession() method returns invalid session.
Status: RESOLVED DUPLICATE of bug 37356
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.17
Hardware: Other Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2006-08-23 12:03 UTC by Suzuki Yuichiro
Modified: 2007-02-14 00:33 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Suzuki Yuichiro 2006-08-23 12:03:04 UTC
I noticed that the counter "accessCount" of StandardSession is not synchronized 
to the session table of the Manager.
That cause a problem.

The Specification 2.4 says:
The session invalidation will not take effect until all servlets using that 
session have exited the service method.

The problem is:
1. First request creates a session.
2. Next request invokes getSession(false).
     In the Request#doGetSession() method,
        2.1. The manager's findSession() method is called.
        2.2. It is checked whether the session is valid by using the session's 
isValid() method.
     We assume that the current thread changes before StandardSession#access() 
is called. 
3. ManagerBase#processExpires() is called.
   In this timing, the session will be invalidated if the session is time-out,
   because the counter "accessCount" is 0.
4. StandardSession#access() is called with the former thread.
5. The getSession(false) method returns invalid session.

However, we were expecting Null or an valid session. 

I think that it is necessary to do some synchronous processing between 
accessCounter and the session table.
Comment 1 Remy Maucherat 2006-08-27 14:34:42 UTC
Note that if it gets too convoluted, we really don't care.

*** This bug has been marked as a duplicate of 37356 ***
Comment 2 Suzuki Yuichiro 2007-02-14 00:33:43 UTC
This issue is different from Bug37356. 
The synchronization of accessCount by Bug37356 is not useful for this issue.

I will return with a simple patch.