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, [EMAIL PROTECTED] wrote:

glenn 2004/04/30 12:15:26

  Modified:    catalina/src/share/org/apache/catalina/session
                        JDBCStore.java PersistentManagerBase.java
                        StandardManager.java StandardSession.java
  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

     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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to