I started working on a legacy web application that was comprised of both classic ASP and ASP.NET. The development box was running win 2003 server x64 with IIS 6.
The application typically uses the standard 20 minute session timeout period, however, for my dev box, I wanted to lengthen that time to avoid having to log in more times than necessary. I set the classic ASP session to 240 minutes, and the ASP.NET session to 240 minutes in the web.config file.
I then proceeded to go to work. A short time later, I was redirected to the login page. Hmm, wierd I thought. Ah, let it go this time. Log in and keep working.
The next day, after my initial log in, once again my session timed out after about 40 minutes and I was redirected to the login page. I double checked my session times, both were still set to 240 minutes.
After a little bit of head scratching, I found my way into the properties of the Application Pool for my web app in IIS. My attention was drawn to the Recycling tab where I noted that my application pool would be recycled every 1740 minutes. Since my sessions were stored "In Process", this recycling would kill my session, however, the timing didn't seem too likely. Nonetheless, I changed the property to configure the worker process to recycle at a specifiec time instead: 3am.
On the Performance tab, I found something even more interesting. An "Idle Timeout" setting that was set to shutdown the worker process after being idle for 20 minutes. Bingo!
So even though my session timeouts were set correctly at 240 minutes, I could still lose my session after 20 minutes because the worker process would be shut down after 20 minutes of inactivity... which might be common on a development machine where you are the only web site visitor and you are distracted by other work or working in other applications for a period of time.
Once I turned off the "Idle Timeout" feature for my Application Pool, my premature session death is a thing of the past.