https://issues.apache.org/bugzilla/show_bug.cgi?id=47281
Summary: Efficiency of the JDBCStore
Product: Tomcat 6
Version: 6.0.18
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: grant-gener...@shaw.ca
I’ve been using the PersistentManager with the JDBCStore. On the surface it
appears to work as designed. However, depending on how it is used, I think it
is somewhat self-defeating.
If it is being used to simply save and restore sessions across application
restarts, then I think it works fine.
If you want to use it to swap out idle sessions and reduce the total amount of
memory theses idle session are consuming, then it is not too effective.
The issues is with in the processExpires method of
org.apache.catalina.session.StoreBase and called from
org.apache.catalina.session.PersistentManagerBase.
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.
It is actually more if we are using the persistent store to back up ( not swap
out) sessions. Since, in that case, we may now have two instances of each of
these sessions in memory.
I’ve implemented a different method to delete expired sessions directly from
the DB, without reloading them into memory.
Effectively executing a SQL statement like:
DELETE FROM tomcat_sessions WHERE app_name = ? AND ( valid_session = '0' OR ?
> (last_access+max_inactive*1000) )
Where the second parameter is set with the System.currentTimeMillis().
But, there is a downside to this approach, in that the full life cycle contract
of the sessions is not observed. No listeners are called when the session is
removed from store.
In my application’s case, this is not an issue. But, it most certainly could
be for others.
Additionally, it could be that for some reason an expired session swapped out
to the store is still in memory. So, we should probably first get the session
keys of the expired sessions before we delete them, and ensure that they are
removed from memory as well.
I am happy to share my work-around, and work on a more robust solution if
anyone is interested.
--
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
