CODEWITHSUNDEEP
javaservletssession-timeout
mebada
mebada

Reputation: 2378

How to call sessionDestroyed when a session times out

I am new to JSP. I used the following code in a class that implements HttpSessionListener to get SESSION OUT when the session times out:

    public void sessionCreated(HttpSessionEvent arg0) {  
        System.out.print("SESSION Created");
    }

    public void sessionDestroyed(HttpSessionEvent arg0) {
        System.out.print("SESSION OUT");
    }

and I set in web.xml:

  <session-config>
     <session-timeout>1</session-timeout> 
  </session-config>

The servlet waits more than two minutes, then it calls sessionDestroyed.

Is there is a way to force sessionDestroyed when time out ?

Thanks in advance.

Upvotes: 4

Views: 13745

Answers (5)

Michał Karpiński
Michał Karpiński

Reputation: 31

Session invalidation does not mean that you session is immediately destroyed. This is in fact implementation dependent and different application servers deal with that in a different way.

In case of Jetty this process is called "Session Scavenging" and you may set the desired timeout with jetty.sessionScavengeInterval.seconds parameter (https://www.eclipse.org/jetty/documentation/jetty-9/index.html):

jetty.sessionScavengeInterval.seconds

This is the period in seconds between runs of the session scavenger. By default it will run every 600 secs (ie 10 mins). As a rule of thumb, you should ensure that the scavenge interval is shorter than the maxInactiveInterval of your sessions to ensure that they are promptly scavenged.

In Tomcat this is taken care of during container's background processing and you may set the timeout with backgroundProcessorDelay engine attribute (https://tomcat.apache.org/tomcat-9.0-doc/config/engine.html):

backgroundProcessorDelay

This value represents the delay in seconds between the invocation of the backgroundProcess method on this engine and its child containers, including all hosts and contexts. Child containers will not be invoked if their delay value is not negative (which would mean they are using their own processing thread). Setting this to a positive value will cause a thread to be spawn. After waiting the specified amount of time, the thread will invoke the backgroundProcess method on this engine and all its child containers. If not specified, the default value for this attribute is 10, which represent a 10 seconds delay.

Please note that these timeouts are not strict - Jetty randomly adds 10% of the timeout, while Tomcat seems to add about 20s to the provided delay.

Upvotes: 0

BalusC
BalusC

Reputation: 1108537

The servlet waits more than two minutes, then it calls sessionDestroyed.

Is there is a way to force sessionDestroyed when time out ?

This is implementation specific (application server dependent). There is a background thread which checks the sessions at timed intervals and reaps all the expired ones. This may occur every minute but can also be every 15 minutes. They will also be reaped immediately if you fire a request while the associated session has already been timed out but not reaped yet.

Thus if you for instance wait one minute and fire a new request, then it will be immediately reaped. There is really no need to worry about that. You don't need to force it to reap them immediately, that would have been an expensive task. You know, it's all just about programming, not about some magic ;)

Upvotes: 3

A_M
A_M

Reputation: 7851

I don't think the J2EE spec makes any guarantees about when the methods on the listener will be called. It just states that they will be called at some point.

I've seen code which worked on one container (Tomcat) but didn't work on another container (OC4J). The developers had made an invalid assumption about when the sessionDestroyed method will be called.

UPDATE

Note that the behaviour of this interface changed in v2.4 of the servlet spec. See page 21 for details.

Upvotes: 1

Andrzej Doyle
Andrzej Doyle

Reputation: 103777

What makes you think that sessionDestroyed is not being called when the session times out? Or in other words, what's you interpretation of the fact it gets called at all?

The servlet will handle the validity of sessions in its own manner, including session timeouts, and when it determines that the session is no longer valid it will call your method. However, I don't think any servlets guarantee any particular timeliness in this regard; my understanding is that it's a bit like garbage collection in that it is guaranteed to happen at some point, but not necessarily at the earliest possible instance that the session becomes eligible for destruction.

In any case, it seems almost certain that the servlet is doing what you want - seeing that the session is timed out and calling the appropriate method - the only question is whether you're going to see this exactly 60 seconds after the last request or a bit later. I would suggest that in general you shouldn't rely on the exact timings of when this method is called; use it to clear up resources, sure, but not for something like program correctness (you'll get IllegalStateExceptions if calling methods on an invalid session anyway). If you feel you really must rely on this, perhaps explain what you're doing so that others can suggest more suitable ways to achieve this.

Upvotes: 5

valli
valli

Reputation: 5921

when you force the user to logout via the invalidate() method that the HttpSessionListener sessionDestroyed() method is called twice, once when they logout, and a second time after some delayed time period. This occurs if after the logout you redirect the user back to a web page within your application. What you're essentially doing is starting another session (which may not be immediately obvious if you haven't added security/authentication requirements to all your web pages), and the delayed second call of the sessionDestroyed() method is a timeout occurring. The simple solution, on logout redirect the user to a web page outside of your application.Read this article session

Upvotes: 1

Related Questions