https://issues.apache.org/bugzilla/show_bug.cgi?id=47281
--- Comment #2 from Grant Genereux <grant-gener...@shaw.ca> 2009-05-28 06:35:44 PST --- (In reply to comment #1) > (In reply to comment #0) > > > Basically speaking; what StoreBase.processExpires() does is > > > > 1. Gets all the keys from the store ( in this case the JDBCStore) > > 2. Loads all the sessions from the JDBCStore > > 3. Removes and deletes any expired session. > > > > The problem is that in step 2 above, we’ve loaded all the fully > > de-serialized > > sessions back into memory. This happens every few minutes with the default > > configuration. > > > > So, at the time of the call to processExpires() the total amount of memory > > being consumed by sessions is no less than if we had not swapped them out to > > the store. > > Are you sure. Looking at the code it loops through the list of sessions doing > steps 2 and 3 above for one session at a time rather than all sessions at > once. Thanks for the quick reply, Yes, but depending upon when the GC thread kicks in. If not during the: for (int i = 0; i lt keys.length; i++) then by the end of that statement, we'll have all the sessions back in memory. Yes, since the reference is not kept, the GC can collect them, but it could be a bit intensive. Thanks -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
