How do I set the timeout on IIS7 ASP.NET 2.0?

  • Thread starter Thread starter David Thielen
  • Start date Start date
I don't have it in front of me, but session timeout is set in the
configuration file(s). In general, you want to do this on a site by site
basis. And you really DO NOT want to set it for 8 hours, even if that is
what you are being told. I understand that is a workday, but it also means
leaving sessions open most of the night, consuming resources, if a person
does not log out. If that is your issue, you are better to force a logout
client side when a person goes past time out and set it to a more reasonable
timeout.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
 
<sessionState timeout="120" />



I set mine for 2 hours very reluctantly and only because my boss wanted it
to go up.
 
if you use sqlserver sessions, a couple of weeks (or more) is fine and I
almost never use less than 12-24 hours (only shorten for security). works
great with shopping cart apps.

just be sure to have a backup of the session database (as its now production
data, unless lost sessions are ok).

-- bruce (sqlwork.com)
 
Also, there's the App Pool idle timeout to take into consideration.

Even if the session timeout is set for 8 hours, if the users don't have any activity
for the time limit set for the App Pool timeout, the application will be recycled, too.

The session timeout can also be set in the Session_Start event :

void Session_Start(Object Sender, EventArgs e)
{
Session.Timeout=1;
}




Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
 
True. And if you hit some limit in the worker process, you could end up
dumped anyway.

Unless, of course, you move to SQL Server as your session state mechanism.
It will even survive deploying new code, as long as the user does not
request during the move. Not that I recommend live hot fixes, but it can be
done. :-)

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
 
There is a trade off here, of course, that you are adding weight to your
system for persistence. I am not stating it is wrong, but the more users the
more it affects scale.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
 
One more thing. If you have a failure on the ASPState database, is it really
wise to restore it? It seems to me that you will end up dumping current
users during the restore so someone who might come back can come back.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
 
Back
Top