views:

366

answers:

2

I am running a J2EE web application in Tomcat, and recently I have been tasked with adding metrics to the application. I am using a SessionListener to detect when the session is destroyed, and then uploading the metrics to a database. My Session timeout is set in my web.xml to 30 minutes, and I am not invalidating the session anywhere programmatically. Often during 1 5-10 minute period of me logging in for testing, I will see 3 or 4 sets of metrics uploaded to the database, all with different session id's.

Besides web.xml and session.invalidate(), what else can cause a session in Tomcat to be destroyed? Exceptions? Will Tomcat ever randomly invalidate sessions?

A: 

This probably isn't what is happening on your server, but if the system time is set forward on the server, this can cause sessions to expire faster than an "elapsed time" of 30 minutes. Tomcat -- at least as of 5.5 -- used "clock time" to expire sessions, so changing the system clock will effect session lifetime.

Eddie
+2  A: 

Possibly your webbrowser has decided to not sent the session cookie on a request to the webapplication, where your application would have expected one. I have seen this happen with an apache rewrite rule; an URL outside the session-cookie path was redirected to the web-application. There something like the folowing happened (details may be wrong):

  • my web application was located at /app/
  • thus the session cookie was bound to this path /app/
  • a page in the webapplication referred to /img/magic.jpeg
  • the browser did not sent the session cookie in its request for this image (path did not match)
  • the server redirected the request (internally) to /app/createImage?magic
  • the web application did not receive a session cookie, so it created a new session

You should be able to see if this causes your problem if you log the initial URL for new sessions.

beetstra