Difference between setting session timeouts using web.xml and setMaxInactiveInterval

Question

I have a requirement where a user is authenticated into a session and after 10 minutes of inactivity, the session times out. Once the session times out any further requests from the now expired session is redirected to a timed out page. I have researched in this regard and came to 2 different approaches.

Approach #1:

In web.xml I have the code mentioned below...

<session-config>
     <session-timeout>10</session-timeout>
</session-config>

Approach #2:

I have the code mentioned below inside the authenticated page...

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setDateHeader("Expires", 0); // Proxies.

request.getSession().setMaxInactiveInterval(600);

Now my questions are:

What is the difference between these two approaches? Which one is better or recommended?

And also when using approach #2, if the end user navigates away from the authenticated page but has not logged out, does the session still times out after 10 mins of inactivity?

Solution 1

Session timeout can be set on various levels:

• In the application server there is usually default settings, that can be changed - it is a default for all applications, or for given application (depending on server config capabilities).
• Then in the application descriptor - you can override it by using web.xml - it will be used for all sessions in the given application
• Then in the application code - you can override it using session.setMaxInactiveInterval(), it will be overridden only for that session

As Roman wrote:

no matter how you set it, it is invalidated by the container when timeout expires.

You should rather avoid programmatic approach (last one), as it is easy to miss some session and it will get the default timeout, and you will have inconsistent behavior. Use web.xml if you want to ensure given timeout (business requirement) and don't want to rely on server capabilities.

Solution 2

The first approach is using a static constant in the configuration for all sessions. The second approach is dynamic where you can set the value using servlet API at runtime dynamically and affected only a session which method is called. Once the value is set the session is invalidated by the container regardless which approach is used. See what the doc says about HttpSession#setMaxInactiveInterval(int):

Specifies the time, in seconds, between client requests before the servlet container will invalidate this session.

An interval value of zero or less indicates that the session should never timeout.

The value in deployment descriptor web.xml is in “minutes”, but the setMaxInactiveInterval() method accepts the value in “seconds”.