Ran across on question on LinkedIn today and thought the answer belonged here as well…

Q: (paraphrased for grammar) How to automatically redirect to the login page after a session time out?

A: Assuming that there is a security session that is separate from your server session,  you can add a hidden AJAX component that checks every n seconds and redirects when the session is closed. When you do this, you need to include in your keep alive call an appended parameter that is incremented or changed randomly each time or else you may get a cached response from the browser and miss that magic time out moment.

If you need to know if the session of the same application on the same server has timed out, there is a chicken and egg paradox as any call to the server to check if the session is still alive will keep the session alive, so it will never time out. I’ve heard of applications that have worked around this, but have not had to research it out as the requirement always resolved to a security session timing out that lived on another server (as described in the first paragraph) or the that simply have the page go to the login page on the next click after the timeout was acceptable.

To go to the login page after the next click in a timed out session, simply fill in the security node of your web.xml completely and the web server will do the rest.

Awhile back, I ran into an issue where session data was being lost between requests in a WebLogic Portal project. As it only occurred in a clustered environment, it was obvious that the value was not being persisted, even though persistence was set properly with

<wls:session-descriptor>
<wls:persistent-store-type>replicated_if_clustered</wls:persistent-store-type>
</wls:session-descriptor>

After much frustration, someone on the team ran across an additional setting for the session-descriptor node: sharing-enabled. In the case where a portlet is from a shared library, the persistence does not work unless sharing-enabled is set to true.

<wls:session-descriptor>
<wls:persistent-store-type>replicated_if_clustered</wls:persistent-store-type>
<wls:sharing-enabled>true</wls:sharing-enabled>
</wls:session-descriptor>

In hindsight, this behavior makes some sense, in that most portlets that are distributed as shared libraries by vendors do not require session values. However, in the case where a shared library is created by an application team to reuse portlets across portals where WSRP is not practical, the need to share sessions may arise, and now you know how to fix it.

For other deployment descriptor options, see http://download.oracle.com/docs/cd/E12840_01/wls/docs103/webapp/weblogic_xml.html