You basically have it right, but it's not the person, it's the request. Each aspx page called on your application will add up and when the threshold is reached, the application pool is recycled, the application domain (if your using .Net) is unloaded and everything starts up again. You lose Session, Application and any static variables laying around. If your using classic asp or php, every session and global variables are lost too.
A number of hits threshold is a bit overkill. You should either disable it or set it to a huge number. By default, if I recall well, the IIS6 application pool recycles every 15 minutes if there were no request and you can also put threshold on the total memory used by your application to trigger recycling.
If your page does not modify any session variables, you can opt out of most of this lock.
<% @Page EnableSessionState="ReadOnly" %>
If your page does not read any session variables, you can opt out of this lock entirely, for that page.
<% @Page EnableSessionState="False" %>
If none of your pages use session variables, just turn off session state in the web.config.
<sessionState mode="Off" />
I'm curious, what do you think "a ThreadSafe collection" would do to become thread-safe, if it doesn't use locks?
Edit: I should probably explain by what I mean by "opt out of most of this lock". Any number of read-only-session or no-session pages can be processed for a given session at the same time without blocking each other. However, a read-write-session page can't start processing until all read-only requests have completed, and while it is running it must have exclusive access to that user's session in order to maintain consistency. Locking on individual values wouldn't work, because what if one page changes a set of related values as a group? How would you ensure that other pages running at the same time would get a consistent view of the user's session variables?
I would suggest that you try to minimize the modifying of session variables once they have been set, if possible. This would allow you to make the majority of your pages read-only-session pages, increasing the chance that multiple simultaneous requests from the same user would not block each other.
Best Answer
If you have a single web server, and you've used the default
InProc
mode for SessionState persistence, then any data that you've added to the session's Dictionary in your server code will be lost during an App Pool recycle - after the recycle, when your code next accesses an entry in theSessionState
dictionary, it will returnnull
.This will similarly happen if you have multiple web servers across a load balancer, with session state incorrectly configured as
InProc
, and the user returns to a different server (i.e. without sticky routing).(The Session State cookie stored on the browser may still be valid for several minutes yet).
The way to allow Session State to 'survive' an App Pool recycle, server crash, or to span across a farm of servers is to persist data stored in
SessionState
, so that the server (or servers) can again retrieve the data when the user's session returns. Easiest is to use one of the out of the box solutions, viz a separateStateServer
process, or store state in aSqlServer
database. Custom persistence is also an option.One caveat - note that any data that you store in an 'out of process' mode such as
StateServer
orSqlServer
needs to be serializable - this can be a breaking change when you switch out ofInProc
.