tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Anderson <tander...@infonow.com>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
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!
~Tom

On Apr 30, 2004, at 1:15 PM, glenn@apache.org wrote:

> glenn       2004/04/30 12:15:26
>
>   Modified:    catalina/src/share/org/apache/catalina/session
>                         JDBCStore.java PersistentManagerBase.java
>                         StandardManager.java StandardSession.java
>                         StoreBase.java
>   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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message