tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Anderson <>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session
Date Fri, 30 Apr 2004 21:27:00 GMT
I'm just a list lurker (so my opinion doesn't "count") but I'm really 
happy to see these fixes.   I have had to override JDBCStore and 
PersistentManagerBase at my site to make similar fixes so that things 
work acceptably (yes, I submitted patches but they weren't accepted).   
Having these fixes in would allow me to upgrade to 4.1.x and get rid of 
my old overridden classes.

Thanks Glenn!

On Apr 30, 2004, at 1:15 PM, wrote:

> glenn       2004/04/30 12:15:26
>   Modified:    catalina/src/share/org/apache/catalina/session
>   Log:
>   The JDBCStore required a great deal of unnecessary db
>   queries to manage the persisted data. This could severly
>   impact its ability to scale to large numbers of sessions.
>   1. When a JSESSIONID cookie was submitted with a request where
>      the Session no longer exists multiple queries of the db occurred
>      to try and load a persisted Session from the Store. I was
>      seeing four attempts to load from the persistence store
>      each request when a Session did not exist for a JSESSIONID.
>      PersistentManagerBase swapIn() and swapOut() were patched
>      to maintain a Hashtable of JSESSIONID's which do not exist
>      in the Store so that they don't have to be checked multiple
>      times.  Each checkInterval the Hashtable is cleared to
>      prevent it from consuming too much memory.
>   2. The StoreBase.processExpires() method triggers a load of
>      each Session persisted to the db each checkInterval to
>      perform its test to determine if the Session has expired.
>      This incurred alot of overhead on the db, especially
>      if there was a large amount of session data. The number
>      of queries performed each checkInterval is 1 + number of
>      sessions persisted to the db + number of expired sessions
>      removed.
>      The StoreBase.processExpires() method was overridden
>      in JDBCStore.  The method in JDBCStore performs a
>      query of the db to find only those Sessions which should
>      be expired. The number of queries performed here is 1 +
>      2 * the number of expired sessions (load then remove
>      of expired session).
>   3. JDBCStore.remove() is being called sometimes with a null
>      sessionid String causing an unnecessary synchronization
>      and db query.
>      Added a check for a null sessionid String at top of method.
>   Problems with expiring sessions have been reported numerous times.
>   The basic problem is as follows, starting at time 0 min and with
>   a max inactive interval of 30 minutes:
>   00 min: First request, new session created, LastAccessedTime 0
>   02 min: Second request, reuse session, LastAccessedTime 0
>   31 min: Third request, reuse session, LastAccessedTime now 2
>   33 min: Background manager thread expires session even though
>           it has only been two minutes since the remote clients
>           last request.
>   The argument for not changing how this works is based on how
>   the Servlet Spec defines Session.getLastAccessedTime().
>   But I agree with all those who have complained about this
>   behaviour that Tomcat session timeouts are buggy.
>   So I came up with a compromise that still allows the
>   HttpSession.getLastAccessedTime() to return the time of the
>   previous request for those who are Servlet Spec purists.
>   But internally sessions are expired when
>   current time > last request + max inactive interval.
>   When we do a major revision we should consider adding
>   the StandardSession.getLastUsedTime() method to the
>   org.apache.catalina.Session interface.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message