mvc Understanding ASP.Net session life time
session and cookies in asp net (4)
I am confused about ASP or ASP.Net session life time (or life cycle) concepts. More specifically, my confusions are:
- How does IIS decide when a new session starts and an existing session ends? Especially how does IIS decide whether a session continues or ends when we call redirect code?
- How can we set session expire time? (Currently I only know to set it through
- Is it possible for one session to access another session's variables?
Session starts because the request does not contain a session cookie or the session cookie it does contain no longer maps to a session. A session ends by a) it has sat idle with no further requests referencing it for the timeout period. b) Its deliberately aborted by code. c) In-process session dies when the process does, e.g. when the app is recycled.
Different ways to change the timeout are basically modifing the web.config anyway or a config file from which the value is inherited.
Not unless the session object is deliberately placed by code somewhere that another session can access it.
Session is generally handled by generating a unique identifier as a cookie on the clients machine. This is usually a session cookie, so you can't easily get to it. When you visit a site that uses sessions, it looks for this cookie. If it doesn't find it, it creates a new one, thus creating a new session.
One way to set the expire time is in the web.config, you can also set it in IIS by going to your website properties -> Home directory tab ->Configuration button -> Options Tab -> Session Timeout.
You will not be able to access someone elses session data.
This is better (albeit polling can be taxing on your server, don't poll too often) because if you set your session timeout to a very high (or infinite...) value you'll end up with asp crashing with an out of memory error (I guess the application pool will be restarted).
The session is kept alive when the user calls any asp page on your application before the timeout expires. If your user closes its browser, there's no way your app will be notified and asp will have to wait for the timeout to clean the memory. That means that the session will stay in memory for n minutes after the user is gone, n being the timeout.
There's no need to have an infinite session (it can be addressed by polling) and tweaking with the timeout parameter will make your application more fragile.
If you want to store information for a long while (basically, for the whole life of your application) you'd better use the Application object, which is a dictionary just like Session but is a singleton and can be accessed by anyone on the server.
ASP.NET Application Level vs. Session Level and Global.asax…confused
Nothing lives outside an
AppDomain so of course the
HttpApplication has to be instantiated inside one.
Step 3 to 6 only happens ONCE in the lifetime of your application. When an
ApplicationManager instance has been created it wont be created again for the next request. The same is for
HttpApplication. This means that values stored in the Application-collection will be remain there to get for all later requests during the lifetime of the application.
There is one
AppDomain per application, not per session or per request.