setmaxInactiveInterval

[Raj Kumar]

What happens if we call HttpSession.setmaxInactiveInterval(0).
Will the session never expire, or will it expire as soon as it is created??
Thanks

[Manjunath Subramanian]

The argument passed is a time interval in seconds after which the session should expire.So giving a value of 0 will terminate the session the moment it is created.
Hope this helps,
Manjunath

[Madhav Lakkapragada]

Manjunath:
As much as I would want to accept your answer, this is what I told myself. Currently I am short of time....
To Do:
Write a HttpSessionBindingListener and see what happens.
Motivation:
The API doen't mention what happens, it only talks abt negative number argument but not zero.
However, according to the Servlet Spec (Page 110, Section 13.3 DTD):
When the session-timeout is zero or less, the container ensures the default behaviour of sessions is never to time-out.
These two maybe different, for all I know, but would like to see an example.
Just making a note to myself.....not to confuse anyone else.
- satya

[Raj Kumar]

Madhav,
As u said the best way would be to write a simple some code and verify it. But as a note, session-timeout and setMaxInactiveInterval have different behaviour. For ex, session-timeout takes minutes as param, whereas setMaxInactiveInterval takes seconds as param... And so on goes the inconsistencies....

[Manjunath Subramanian]

Well I tried a piece of code to test this.
TestingSessions.jsp
*******************
<%
out.println("In Jsp");
session.setMaxInactiveInterval(0);
%>
And the listener class..
import javax.servlet.*;
import javax.servlet.http.*;
public class TestListener implements HttpSessionListener{
public void sessionCreated(HttpSessionEvent h){
System.out.println("Session Created in TestingSessions");
}
public void sessionDestroyed(HttpSessionEvent h){
System.out.println("Session Destroyed in TestingSessions");
}
}
I then added the listener and the listener-class
in web.xml.
After i entered the URL in the browser i went to the "CATALINA" window to check the messages.
I found "Session Created in TestingSessions" as one of the outputs.I brooded on this for some time and then when i go back to the same window,
and what do i find.....the message..
"Session Destroyed in TestingSessions".
I timed the difference between the first and the second message and it turned out to be 40 seconds.
(Am using tomcat-4.0.1).
I tried this repeatedly after shutting down the server and restarting it only to find the same
obeserved output.
setMaxInactiveInterval(int n) where n is a negative integer works fine where the session never times out.I have not defined the session-timeout element in the web.xml.
Cant wait to hear your versions of the story.
Manjunath

[Raj Kumar]

So Manjunath, based on ur experiment, probably its true that if we set it to zero, the session times out immediately. (Thats not the best use of it though, I mean why use session if u want it to expire immediately!) Thanks for ur help

[Manjunath Subramanian]

I am not pretty sure of what is happening.Even the DTD says that for a time out of 0 or less ,the container should ensure that the session should never time out.May be i am missing something here.. Would love to see what Satya has to say...
And then if you implement the HttpSessionBindingListener the time between the outputs is different even though the output is the same for a setMaxXXX(0).Moreover i just obeserved that the session is destroyed even for other applications along with this application.
Somebody throw some light on this..
Manjunath

[Srini Admala]

Here are the inconsistancies :
on page 51 of the spec under Session Timeouts SRV.7.5
"if the timeout period for a session is set to -1,
the session will never expire"
AND
on page 110 in the web.xml dtd
"If the timeout is 0 or less, the container ensures the default behaviour of sessions is never to time out"

Going by Manjunath's test, can we say that the session will never timeout ONLY for -1 and not 0 ?

BTW, I'm taking the test tomorrow and I wouldn't want to see a question on this topic
-Srini

[Madhav Lakkapragada]

System.out.println("Session Created in TestingSessions" + new Date());
System.out.println("Session Destroyed in TestingSessions" + new Date());

I was thinking the code would be more helpful with the Data string attached. That way you don't have to time it. You would know it more pricisely.
Currently, I don't have access to a computer with jdk, I will be able to checkin late in the evening.
Its possible that these two (MaxInterval?) and timeout may have different behavior. I have to test in order to say something.
Also, keep in mind that to invalidate a session, you could use the HttpSession.invalidate() method rather than setMaxInactiveInterval(0);
I will check back late in the night.
- satya.....had a really busy day running around!!! I feel worn out.

[Madhav Lakkapragada]

and BTW, just clarifying one of the stmts that was made....
even if you haven't set any session-timeout, the session is bound by the default app server session-timeout, IMO. For Tomcat 4.0.1, this is 30 mins.
- satya

[Madhav Lakkapragada]

I finally got a chance to test this........
Manjunath, thanks for the code.
Seems like your observation is correct. The session gets destroyed immediatele (40 secs or 50 secs machine dependent lag).
On my NT system with Tomcat 4.0.1 I got this:

Session Created in TestingSessionsTue Feb 19 12:11:07 EST 2002
Session Destroyed in TestingSessionsTue Feb 19 12:11:57 EST 2002
I will now try to call invalidate() and see what that would do........
For what its worth.........
- satya

[Madhav Lakkapragada]

WOW!!!
invalidate() is the best call you can make based on this observation..........check the time difference. Almost instanteneous.

Session Created in TestingSessionsTue Feb 19 12:17:32 EST 2002
Session Destroyed in TestingSessionsTue Feb 19 12:17:41 EST 2002

Good finding I think.
- satya
Edited:
I should mention, I have a FORM based security constriant, so you do have to account the time for authentication/authorization.
This applies to both the examples above.
Moral:
Use session.invalidate() rather than setMaxInactiveInterval(0). You don't want to perform a $1000.00 transaction in the 50 second time lag after your customer has signed-out.
- satya
[ February 19, 2002: Message edited by: Madhav Lakkapragada ]

[Chintan Rajyaguru]

This means that the processing the container has to do when it encounters
HttpSession.setmaxInactiveInterval (int n)
is different from the processing when it sees
HttpSession.invalidate ()
In the first case I think the lag is due to the fact that container has to call listener methods and do "other things". Container may ot have to do those "other things" in case of invalidate ().
It would be interesting to find out what those "other things" are and if they are same for different containers.

[Jessica Sant]

Originally posted by Chintan Rajyaguru:
This means that the processing the container has to do when it encounters
HttpSession.setmaxInactiveInterval (int n)
is different from the processing when it sees
HttpSession.invalidate ()
In the first case I think the lag is due to the fact that container has to call listener methods and do "other things". Container may ot have to do those "other things" in case of invalidate ().
It would be interesting to find out what those "other things" are and if they are same for different containers.

So... just to revive a dead thread and hopefully offer some insight from an app server point of view: I can explain a bit how our old App Server dealt with this (Bluestone Total-e-Server 7.3) I *think* the new one (HP Application Server 8.0) uses the same basic process:
We've got this snazzy thing called a Session Reaper that is a thread that goes through all the current sessions checking their inactiveTime and comparing them to how long their supposed to live... if the session has timed out, it then invalidates the session, removes all the session objects and generally cleans up.
-- So if your session-timeout is set to 30 seconds but your sessionReaper only runs every 60 seconds... your session could really last anywhere from 30 seconds to 90 seconds.
-- When you call session.invalidate() there's no need for the reaper, the container cleans up the session as soon as its called.
** and just so you don't think us app server developers never have any fun.... our SessionReaper even had the following method:

   /**
    * Method - isGrim - Is grim ?
    *
    * @return result true this reaper *is* grim!
    */
   public boolean isGrim()
   {
      return true;
   }

get it??