Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.2.1
-
None
-
Websphere 6.1, possibly others too
Description
On certain web containers and especially Websphere, expired session are cleaned up in a background job which might sometimes take several seconds before executed.
During that "interval" period, incoming requests trying to access such a session might actually still "see" it, but be confronted with a IllegalStateException when trying to use/access session attributes.
And, in portal environments which use cross-context dispatching across multiple web applications with individual background cleanup of each their sessions, this all might become very tricky to deal with without being hit by such IllegalStateExceptions.
To prevent this potential problem, I'll add a new static utility method which will check a (servlet) session if it might already be expired (time-wise) and then invalidate/recreate it (optionally).
This logic already is used within Pluto PortletRequestImpl.getPortletSession(boolean create) but that only executes on portlet application level, and actually in some situations makes things worse if a (also time-wise expired) portal session is kept "alive".
By ensuring this (portal) session check is run at the earliest stage within the portal, combined with the Jetspeed PortalSessionManager handling, time-wise expired (portal) sessions will be cleaned up automatically first, as well as possible portlet application sessions too (thanks to the PortalSessionManager logic).
The best "place" to put this check will be within a top level filter mapped to /*, e.g. like within the Jetspeed PortalFilter.
But as not all Jetspeed installations will need/use the Jetspeed PortalFilter (using default container managed security instead), I'll create a new SessionValidationFilter too and wire that in the default Portal web.xml.
I also will add the same logic to the Jetspeed PortalFilter, so for those using (only) that the same logic will be performed.
Note: having both Filters in place doesn't really hurt either: the check will be efficient if/after a session is (re)created anew.