Most ASP.Net applications using sessions are data driven applications. Usually these kinds of applications use the “Inproc” mode for their session. During development the developer does not encounter any kind of problem with the session. When deploying the application the problem arises one by one. In this article I just want to share some thoughts and my professional experience on this issue.
Shared Hosting
Long ago I developed a small application and bought a shared hosting plan. The pain started then. What happened is that the session was shared between the user and the session expired soon. After some chatting with my provider I came to understand that they also use web farms (also using a Load Balancer) with shared hosting. To maintain the session of a user, the machine key must be the same among the servers. But those kinds of provisions were not provided by that host provider. However, the session timeout was set to 20 minutes. If the Load balancer problem is fixed then the user will also be pushed out from the application after 20 minutes.
So what my point here is, if you have an application tightly coupled with the Session then you should consider doing what is explained here.
Apart from the preceding, if you have hosted your application in an individual server and encountered it in your environment then you should consider the following points.
In Web.Config
Long ago I developed a small application and bought a shared hosting plan. The pain started then. What happened is that the session was shared between the user and the session expired soon. After some chatting with my provider I came to understand that they also use web farms (also using a Load Balancer) with shared hosting. To maintain the session of a user, the machine key must be the same among the servers. But those kinds of provisions were not provided by that host provider. However, the session timeout was set to 20 minutes. If the Load balancer problem is fixed then the user will also be pushed out from the application after 20 minutes.
So what my point here is, if you have an application tightly coupled with the Session then you should consider doing what is explained here.
Apart from the preceding, if you have hosted your application in an individual server and encountered it in your environment then you should consider the following points.
In Web.Config
- Session State Node: As a first step, check that web.config contains a valid entry on the “sessionState”. The “timeout” attribute denotes the idle time in minutes before a session is abandoned. By default, the time is 20 minutes. You can find more info about the “sessionState” in MSDN.
- Form Authentication: Sometimes form authentication will create some tricks. Scott Hanselman gives a detailed overview on this topic.
In IIS
In IIS, select the “Application Pools” node and select the application pool you have used and then select “Advanced Settings”.
In IIS, select the “Application Pools” node and select the application pool you have used and then select “Advanced Settings”.
In the “Advanced Settings” popup, under the “Process Model” set the property “Idle Time-out (minutes)”.
There is another property called, “Regular Time Interval” under the “Recycling” node. This property is used to specify the period of time after which the application pool will recycle.
Apart from these, sometimes anti-virus software will do the trick. During the scanning of the web.config file it will update the web.config file's date time (not the content). Which can be notified by the ASP.Net runtime, in turn it will recycle the app pool. To prevent this from happening, it is always best to keep the web.config file away from
No comments:
Post a Comment