Does the OnSessionStart / Session_Start event still only fire once (total) in a server farm environment, or since requests are handled by multiple servers, could it fire up to once per server?
ASP.NET / IIS6 or 7
It should not be assumed that the server is using Sticky Sessions.
With a default installation of IIS the answer is "no" -- the Session_Start will in general fire multiple times. A client will create a new Session on each different server it hits. The same thing goes if you are using the Web Garden option in IIS.
If you don't depend on Session and you have a server farm you are usually best off disabling Session state completely. Here is how you do it:
http://support.microsoft.com/kb/306996
If you do depend on Session your best option is probably the ASP.NET State Server Service. All the servers in your farm will use a single server for Session state, and that will ensure that Session_Start only fires once. For lots of background and detail on setup read this (Look for "State Server Mode" to get specific instructions):
http://aspdotnetdevs.blogspot.com/2008/12/aspnet-session-state-and-modes.html
In addition to Thomas: It depends on your Session State settings.
in web.config, <sessionState mode="" >
If you use mode="InProc" you'll get multiple Session and SessionStart events, 1 per visited server.
In the other modes (StateServer or SqlServer) you'll get 1 session and 1 SessionStart. You will not get a SessionEnd event at all.
In a farm, you would be using either Sql Server or a State Server for managing session state across all the servers in the farm. It is having this single server looking after your state than ensures that OnSessionStart should only be called once per session and there is no need to have to always have all the requests go back to the same server.
The main downside of using a single server for maintaining session state is that you no longer have an OnSessionEnd event.
my understanding is that once a request reach a server in the farm ,all of the upcoming requests of the same client should be redirected to the same server in the farm.
Related
Site hosted via IIS 7.0
I would like to set my session time-out to 9 hours in my ASP.NET application.
This has been set at web.config
<sessionState timeout="540"></sessionState>
But, as I understand, if the timeout is set as 20 minutes inside the IIS where the website is hosted, setting an extended session state will be of no use.
Firstly, I would like to confirm whether this assumption is right.
The problem is that I do not have access to the IIS of my shared hosted web server.
Now, after some research, I came up with another solution in code project. This sounds like a wonderful idea. The idea is to insert an iframe to master page. The iframe will contain another page with meta refresh less than 20 minutes.
Response.AddHeader("Refresh", "20");
This idea seemed good for me. But the article is 7 years old. Plus at comments section a user complaints that this won't work if the page is minimized and I am worried that the same happens when my pages tab is not active.
I would like to know these things
Whether the refresh method will work for my scenario , even if the page is minimized?
Are there any other methods that could increase session time out that overrides IIS timeout setting?
Also I read some questions in Stack Overflow where the answers state that the IIS session timeout is for clasic ASP pages. Then why is not my extended timeout not firing?
Firstly, I would like to confirm whether this assumption is right.
Yes, this assumption is absolutely right in case you are using in-memory session state mode. In this case the session is stored in memory and since IIS could tear down the AppDomain under different circumstances (period of inactivity, CPU/memory tresholds are reached, ...) the session data will be lost. You could use an out-of-process session state mode. Either StateServer or SQLServer. In the first case the session is stored in the memory of a special dedicated machine running the aspstate Windows service and in the second case it is a dedicated SQL Server. The SQL Server is the most robust but obviously the slowest.
1) Whether the refresh method will work for my scenario , even if the page is minimized?
The hidden iframe still works to maintain the session alive but as I said previously there might be some conditions when IIS unloads the application anyway (CPU/memory tresholds are reached => you could configure this in IIS as well).
2) Are there any other methods that could increase session time out that overrides IIS timeout setting?
The previous method doesn't increase the session timeout. It simply maintains the session alive by sending HTTP requests to the server at regular intervals to prevent IIS from bringing the AppDomain down.
3) Also I read some questions in Stack Overflow where the answers state
that the IIS session timeout is for clasic ASP pages. Then why is not
my extended timeout not firing?
There is no such thing as IIS session timeout. The session is an ASP.NET artifact. IIS is a web server that doesn't know anything about sessions.
Personally I don't use sessions in my applications. I simply disable them:
<sessionState mode="Off"></sessionState>
and use standard HTTP artifacts such as cookies, query string parameters, ... to maintain state. I prefer to persist information in my backend and retrieving it later using unique ids instead of relying on sessions.
Hey I have the following line in my web.config
<sessionState mode="InProc" timeout="45"/>
Which I thought would keep sessions intact for 45 mins
But I have seen the case where if a user is inactive for lets say 15 mins the sessions times out.
How can I stop this ?
Edit : Just noticed I have the following line in the master page
meta http-equiv="Refresh" content="1800;URL=http://www.virtualacademy.ie/login.aspx">
Maybe this is causing the issue, what is the above line doing i.e the number 1800
Be sure to check your IIS configuration because the application pool that your site is hosted on also has its own timeout value which will override your own .config.
To increase it,
Open IIS
Select Application Pools on the left side
Select the Application Pool used by your site
Choose advanced settings
Under Process Model categtory increase the 'Idle Time-out' value to the desired length.
Hope this helps.
(If you do not have a dedicated server / access to IIS with your hosting provider you will have to contact them to see if they can increase it for you)
If the user closes their browser or clears cookies, or if the AppDomain on the server is recycled, the session state will be lost.
Have you checked logs to see if the app is recycling?
AppDomain recycles are a very common problem for this if the sessionState is InProc. It is very much advised to use a StateServer or SQLServer for production systems instead. See Session-State Modes for documentation on how to use each, and the pros and cons of the three different types.
Personally, we use SQL Server if we must for web server farms--slower but can be shared. We use State Server if the site will only be hosted on a single web server--state survives AppDomain restarts, but not entire server restarts.
Also, in the past we have used an AJAX post in the background while the user is watching long running videos or performing long client-side tasks, so that the session timeout gets reset every few minutes. Nothing special about this code--just have a little JavaScript hit every few minutes some ASPX page that returns nothing.
Are you using Forms Authentication? It has its own timeout setting that when expires will redirect the user to your login page even if their session is still valid.
I'm having a problem of losing session variable on my website. It append at random times so there is no particular behavior that cause this. What can be the cause of this session lost?
I've read everywhere on this site that I could put my session in "sql server" mode so everything is written on the server, can it be a solution?
My server is on 1and1 shared hosting, can it be their fault?
Thanks !
Check with the hosting provider that your application is not being hosted on a load balanced server. If the server is being load balanced, your users will lose their session state information when the load balancer sends their request to another server. There are 3 settings Session State mode property:
InProc - Will store state information locally on the server from which the request is made (only effective when the application is being hosted on a single server in a non-load balanced environment)
StateServer - Allows a specially configured server to host state information for an entire web farm (I believe StateServer began to be offered on .NET Framework v2.0).
SqlServer - Allows a specially configured SQL Server instance to store session information for a web farm
[This information will vary slighty in a web garden scenario.]
See MSDN for more information on Session State.
This can happen very randomly based on their load balancing settings (think: sticky load balancing) and can work for several minutes one time and fail almost immediately another time.
The other possibility is the timeout property of the sessionstate setting in the web.config has been set to a low value (it is in minutes) and the session is expiring.
I read two MSDN articles on Session state modes in ASP .Net. 1 and 2.
Both articles shows that 'In Process' session state mode is the only mode that supports the Session_OnEnd event. If the session state Mode is StateServer or SQLServer, then the Session_OnEnd event in the Global.asax file is ignored. If the session state Mode is set to Custom, then support for the Session_OnEnd event is determined by the custom session-state store provider.
Can anyone please give me any reason why it will ignore Session_OnEnd event for StateServer or SQLServer modes?
I think that performance is the main issue. In all but the InProc mode, there are several Webservers responding to requests and 1 Server (Might be clustered SQL) handling the state.
Now, who would be responsible for handling the timeout? It would have to be the State server, but we want to burden that server as little as possible. And it would require the state server to Push data out to a (random) webserver, for everything else it is Polled. I doubt that currently the State server even keep a list of the Webservers, they don't need to. So, just for the SeesionEnd event, it would be necessary to add a complex system for administration an monitoring of WebServers.
Add to that the complexity of tracking whether the selected server did indeed complete the event and it all becomes very unattractive.
StateServer and SQL Server modes are running in a configuration where they could be servicing N number of clients in a load balancing scenario and would have to maintain this list and send out messages across process/machine to signal the Session_OnEnd. InProcess knows that Session is managed within the same process as the application so sending the callback to a single listener is straightforward and inherent to the .NET Framework. If you don't like this you could write your own handler, but be aware of the cavaets.
I have an iframe keep alive (iframe that hits a page, defibrillator.aspx, on my site every few minutes to keep the session alive) on my masterpage for an asp.net app. This works most of the time but every so often my session variables return null during the page load on my defibrillator page. At first, I thought the session was being timed out by the server for some reason so I put some logging into the Session_End event in the global.asax but it was never hit.
Any ideas what could cause the session to be lost.
Many things can cause session to be lost. An AppPool recycle, iisreset, the client could lose its session cookie, etc. Without knowing more it is difficult to tell what is the problem.
If session is so critical that you poll the application to keep the worker process from sleeping perhaps you ought to look into persisting your session state to SQL Server.
Peter Bromberg outlines the primary reasons for ASP.NET session timeouts on his blog.
I had this same sort of problem, storing a shopping cart state in Session but having it randomly return null instead. I think I found the answer on Bertrand Le Roy's blog, which seems to work for me:
Session loss problems can also result
from a misconfigured application pool.
For example, if the application pool
your site is running is configured as
a web farm or a web garden (by setting
the maximum number of worker processes
to more than one), and if you're not
using the session service or SQL
sessions, incoming requests will
unpredictably go to one of the worker
processes, and if it's not the one the
session was created on, it's lost. The
solutions to this problem is either
not to use a web garden if you don't
need the performance boost, or use one
of the out of process session
providers.
Blog
If the chosen persistence mechanism is InProc then it can be triggered by many things. Totally counter-recommended for a production environment.