like the title shows I want to know what is the difference between "InProc" & "stateServer" mode in SessionState on ASP.NET.
Thanks
In InProc mode, a live Session object is stored in RAM in the ASP.NET worker process (aspnet_wp.exe). It is usually the fastest, but more session data means the more memory is used on the web server, and that can affect performance.
In StateServer mode, each session is converted to XML (serialized) and stored in memory in a separate process (aspnet_state.exe). This state Server can run on another machine.
ASP.NET Session State FAQ
This MSDN article covers SessionState in detail.
Off - Used to disable sessions on website.
InProc - Sessions are stored inside of application's process on web server. Depending of IIS version used that could be aspnet_wp.exe or w3wp.exe.
StateServer - Sessions are stored using State Server windows service.
SQLServer - SQL Server database is used to store sessions' data
Custom - Manage session state using custom session state provider. Storage could be anything you implement in provider.
To specify session state mode in web.config, select one of these values for sessionState mode parameter:
In web.config file, <sessionState> element is located under <configuration>, <system.web> element.
Related
How/where is the ASP.NET cache managed in IIS 7? I know that it's stored in the server's memory, but what is the process that manages it? Is it in the address space of w3wp.exe, or is it in another process/location? And does Session data use the cache, or does Session work differently?
You configure where Session data gets stored in your web.config with the sessionState element. If set to InProc, it will be stored in memory in the w3wp.exe process that corresponds to your application's App Pool. You could also, for example, store it in a SQL Server instance.
If that element isn't defined in your config file, check out the machine level web.config for your target framework version / architecture.
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.
Authentication cookies seem to timeout after a short period of time (a day or so). I am using Forms Authentication and have the timeout="10080" with slidingExpiration="false" in the web.config. With that setting, the cookie should expire roughly 7 days after the user is successfully authenticated.
This worked as advertised with IIS6, but when I moved the site to IIS7, the cookie expires much quicker. I've confirmed this behavior on multiple machines with IE and Firefox, leading me to believe it's an IIS7 setting.
Is there a hidden setting that is IIS7 specific related to authentication? All other authentication types are disabled for the website, except for anonymous user tracking.
The authentication cookie is encrypted using the machineKey value from the local web.config or the global machine.config. If no such key is explicitly set, a key will be automatically generated, but it is not persisted to disk – hence, it will change whenever the application is restarted or "recycled" due to inactivity, and a new key will be created on the next hit.
Resolving the problem is as easy as adding a <machineKey> configuration section to web.config, or possibly (preferably?) to the machine.config on the server (untested):
<system.web>
...
<machineKey
validationKey="..."
decryptionKey="..."
validation="SHA1"
decryption="AES"/>
...
</system.web>
Google generate random machinekey for sites that can generate this section for you. If your application deals with confidential information, you might want to create the keys yourself, though.
My understanding is that cookies are expired by the consuming party - the browser, which means that IIS has no say in this
Set session state configured in IIS as
In Process
Use Cookies
Time out = your required time
Use hosting identity for impersonation
Also set EnableSessionState to true (which is default too)
And most importantly run the app pool in classic mode.
Hope your problem will solve.
First of all i must say that these "guidelines" are generic and not iis-7 exclusive.
In web.config under <system.web>
you either have <sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" timeout="130" cookieless="false"/> (which requires the ASP.NET Session State Server service running on localhost)
or <sessionState mode="InProc" timeout="130" cookieless="false"/>.
The main difference is that in InProc that session state data are placed in the application process itself. In the other setting a different service is doing the storage, and you application just polls it to get the required data.
Having used both (as well as sql-server session state mode) the InProc is the least reliable but the fastest. The Sql-server is the most reliable and the slowest and the StateServer mode is somewhere in the middle being unreliable only in the case of a power/system failure. Having said that, i must say that for site with a low request count the performance penalty is negligible.
Now, my experience has shown that InProc is quite unpredictable on its stability; i used to have the same problem with you. I was able to extend the stability of the application by tweaking the settings of the application pool, i removed the problem altogether by switching to SessionState (which also allows to bring down the application and not lose session state data).
The reasons that you may suffer from application/session stability:
IIS and application pooling. Each virtul directory of a website is assigned to an application pool (by default to "DefaultAppPool") which has a series of settings amongst which you define the interval that the process is "recycled" - and as such preserve system resources. If you don't change the settings the application may trigger one of the criteria for the process recycler, which means that your application is busted
Antivirus.
In a ASP.NET application if the web.config (and any child .config files the application depends on) file is touched the application is restarted. Now there are cases where an antivirus program may touch the web.config file (say once a day?) and as such the application is restarted and session data is lost.
Bad configuration
Specifically for Forms Authentication the time-related settings and behavior always where dependent on the web-session with the auth-session being under the web-session.
What i don't know is if the Forms Authentication module depends only on Session domain or if it also places data in the application domain as well. If the second is the case then you may have to disable all recycling settings in the Application Pool as well as checking again configuration/antivirus and who stores the session data.
I recently had the same problem where my site was timing out every 20 minutes even though I set the session timeout to 2 hours. I found that it was because IIS worker process was timing out every 20 minutes: http://technet.microsoft.com/en-us/library/cc783089(WS.10).aspx
In the web.config file for my application, in the <sessionState>
section I have set timeout="60" (in minutes), but session state
variables in my application seem to be expiring in about 1 minutes.
Any idea what could cause this?
Yes.
Session timeouts are also specified and controlled by IIS (although there is overlap ofcourse). In IIS 6.0 you also need to check the following places in IIS manager (properties of Virtual directory):
ASP.net tab > Edit configuration > Authentication tab > Cookie timeout
ASP.net tab > Edit configuration > State management tab > Session timeout
Setting all these to the same value, fixed the issue for me.
edit: Apparently the previously listed first option, had nothing to do with it. That means, that the first of the two options is now the place for you to fix your session timeout. It's probably not your session timing out, but the authentication expiring.
Or another possibility is that the worker process is restarted, or the application is restarted. Also things to look into.
If you are storing session state "in proc" then every time the app pool recycles you can loose session (this can happen a lot on a server with low memory). You could try storing session state "out of proc" using State Server or SQL Server.
See PRB: Session Data Is Lost When You Use ASP.NET InProc Session State Mode
How Can I persist a User-Specific data for an ASP.Net application.
I tried Session Variable - Not good when the worker process recycles.
I need something that can be accessed GLOBALLY by any class of my application.
Advice most welcome.
I tried to utilize asp.net session State Server but I got some DLLs crashing because they are Unserializable.
Is there any other way to have a persistent variable across the application?
ASP.NET session state can be configured to persist to a database.
Here is a tutorial on how to set that up.
Store Data in a Database (such as SQL Server).
You should use Session. You can access session state globally in a class like this...
HttpContext.Current.Session
To avoid losing sessions by the worker process recycling, use StateServer mode.
You can change the Session State Server to not be in process which will make it far more stable and also seperate it from the worker process (You'll need to be able to start the Asp.NET State Service on the server if it's not already running)
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"/>
Also if you need to share it across applications in the same domain you should be able to give them the same machine key
Theres nothing you can really do about the process recycling. If you use the Cache smartly to retain information in a more global sense but you still have the same worker process limitation.
I try and design my app in a n-tier setup with business entity objects. The factory methods for my objects use the cache kind of like a lazy instantation pattern. If its in the cahce, pull it. If not, put it into the cache for next time.
i.e
MyAppsNameSpace.MyBusinessLayerNameSpace.MyObject.GetObject(objectID)
now when this returns my object, it may be from the cache or may not, if the object is under high usage then it will be probably be cached.
This can be used throughout your entire app and because the caching mechanism is maintained centrally you dont really have to worry about it.
You could use the Profile Provider with a SQL database as your backing store.
See this MSDN Article
If you lose data when the worker process recycles then you should stop using the InProc persistance mode for the Session. Use StateServer or SQL Server. Ultimately you could build your own session persistance module if neither satisfies you.