When exactly is the HttpSession expired (starts being eligible for destroying - not necessarily destroyed yet)?

Question

I would like to know when exactly an HttpSession would be expired (not the same as destroyed)?

I am trying to figure out if session.getLastAccessedTime() + (session.getMaxInactiveInterval() * 1000) will give me the exact time in milliseconds of session expiry each time a request comes with the same session id!

From the javadocs:

long getLastAccessedTime()

  Returns the last time the client sent a request associated with this session, as the number of milliseconds since midnight January 1, 1970 GMT, and marked by the time the container received the request.    

int getMaxInactiveInterval()

  Returns the maximum time interval, in seconds, that the servlet container will keep this session open between client accesses.  

Lets say we have the following:
Treq1 - the time the container received the 1st request (HttpSession.lastAccessedTime)
Tresp1 - the time the container sends the 1st response
Preq1 - the time period between Treq1 and Tresp1 (the time period that the server processes the 1st request
Treq2 - the time the container received the 2nd request (HttpSession.lastAccessedTime)
Preq1req2 - the time period between Treq1 and Treq2 (the time between requests entering the container)
Presp1req2 - the time period between Tresp1 and Treq2 (the time between the 1st response exiting the container and the 2nd request entering the container)

So now, when does the server calculate the session as expired? When:
1. Treq1 + maxInactiveInterval < Treq1 + Preq1req2 => maxInactiveInterval < Preq1req2
2. Tresp1 + maxInactiveInterval < Tresp1 + Presp1req2 => maxInactiveInterval < Presp1req2

This part, the servlet container will keep this session open between client accesses is a bit confusing. Does it mean between requests entering the container or between response exiting and requests entering?

On a side note, I know that the session might not be destroyed at the exact time of expiry, but I don't know yet if it is destroyed before any request processing logic occurs in the container. I am referring to the request that holds an expired session id.

Kind Regards,
Despot

Answer 1

The session mechanism is part of the Servlet specification, which mandates:

In the HTTP protocol, there is no explicit termination signal when a client is no longer active. This means that the only mechanism that can be used to indicate when a client is no longer active is a time out period.

The default time out period for sessions is defined by the servlet container and can be obtained via the getMaxInactiveInterval method of the HttpSession interface. This time out can be changed by the Developer using the setMaxInactiveInterval method of the HttpSession interface. The time out periods used by these methods are defined in seconds. By definition, if the time out period for a session is set to -1, the session will never expire. The session invalidation will not take effect until all servlets using that session have exited the service method. Once the session invalidation is initiated, a new request must not be able to see that session.

The getLastAccessedTime method of the HttpSession interface allows a servlet to determine the last time the session was accessed before the current request. The session is considered to be accessed when a request that is part of the session is first handled by the servlet container.

It is probably safe to assume that the "inactive interval" starts with the "lastAccessedTime".

Answer 2

I am trying to figure out if session.getLastAccessedTime() + (session.getMaxInactiveInterval() * 1000) will give me the exact time in milliseconds of session expiry each time a request comes with the same session id!

since you can access session object only in a request thread I am assuming you are having above code in a servlet for informing client(browser) on what time he can take before his next click, may be a timeout counter.

I assume System.currentTimeMillis() + (session.getMaxInactiveInterval() * 1000) will be more accurate in that case.