Thanks Glenn! ~Tom
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
