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.
Related
I've read several threads about this topic and need some clarification on a few sentences I read in a book:
If you store your Session state in-process, your application is not scalable. The reason for this is that the Session object is stored on one particular server. Therefore storing Session state in-process will not work with a web farm.
What does "scalable" in the first sentence mean?
Does the third sentence means if my app resides on a shared web host, I shouldn't use Session["myData"] to store my stuff? If so, what should I use?
Thanks.
1:
Scalability in this sense:
the ability of a system, network, or process, to handle growing amounts of work in a graceful manner or its ability to be enlarged to accommodate that growth.[
2:
Use a session server or store sessions in SQL Server, which are described here.
ASP.NET can store all the combined Session information for an Application (the "Session State") in 3 possible places on the server-side (client cookies is also possible but that is a different story):
"InProc" (In Process) which means in memory on the IIS server attached to the asp.net worker process,
"StateServer" which is a separate process that can be accessed by multiple IIS servers but still stores the Session state in memory, and
"SQLServer" which stores the Session state in a SQL Server database.
1) The reason In-process is not scalable is if your needs exceed the capacity of a single IIS server, multiple servers can't use an In-process session state. If you have determined a shared hosting scenario will fulfill you needs, you don't need to worry about it.
2) When you store something in Session["Name"], ASP.net stores that data wherever the application is configured to store Session state. If you want to change where Session state is stored, all you need to do is configure your web.config file. If you are using a shared hosting environment, your IIS deployment is considered single server even though no doubt the actual servers are in a farm of some sort.
See: MSDN Session-State Modes
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.
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.
What happen if web.config gets updated while ASP (ASP.NET 2.0) server still process client request?
- Will the process be killed?
- If not, will the process read the updates in web.config.
thanks for any input
The new web.config is effectively a copy, so an ongoing request will finish unaffected -- it will not pick up the changes. When the request is complete, the new web.config will be written over the old one and subsequent requests will work from the updated values (in a new application domain).
Microsoft: "ASP.NET will serve all pending requests before restart"
-- http://msdn.microsoft.com/en-us/library/ms178473.aspx
When an application restart is
required, ASP.NET will serve all
pending requests from the existing
application domain and the old
assemblies before restarting the
application domain and loading the new
assemblies.
and following the flow of logic through changes to the asp.net Web.config file ...
"Configuration Changes Cause a Restart of the Application Domain"
The app effectively restarts. However there is also a trick noted in this first blurb to work around that "issue".
Changes to configuration settings in
Web.config files indirectly cause the
application domain to restart. This
behavior occurs by design. You can
optionally use the configSource
attribute to reference external
configuration files that do not cause
a restart when a change is made. For
more information, see configSource in
General Attributes Inherited by
Section Elements.
Attempts to change a configuration
file by someone who does not have
permission to edit the file will not
cause a restart of the application
domain.
^-- http://msdn.microsoft.com/en-us/library/ackhksh7.aspx
Loss of State
Your application, session and other states will be lost if stored in process ...
When using the in-process
session-state mode, session-state data
is lost if aspnet_wp.exe or the
application domain restarts.
^-- http://msdn.microsoft.com/en-us/library/87069683(VS.71).aspx
The life-cycle implications of
information stored in application
state. The .NET Framework application
domain or the process hosting a
.NET-based application can be torn
down and destroyed at any moment
during application execution (as a
result of crashes, code updates,
scheduled process restarts, and so
on).
^-- http://msdn.microsoft.com/en-us/library/bf9xhdz4(VS.71).aspx
Etc...
Just some miscellanei. Info about storing session state out of process.
^-- http://msdn.microsoft.com/en-us/library/ms178586.aspx
I believe that if you make any changes to web.config, ASP.NET automatically reloads your application by recycling the application pool. This of course will result in Session, Application, and Cache data of an InProc session state being lost.
The AppDomain will be unloaded after the request finishes.
A website that I'm working on is making extensive use of the HttpContext.Current.Application store to cache lookup data from the database. (This isn't a lot of data - just simple things that are used in drop down lists etc..)
A few questions about this approach:
Does this store have a lifetime (in the same way that a user's session will time-out after 20 minutes, does the application store timeout)?
Do events in IIS or events in the same App Domain as the website cause the Application store to refresh? (I understand that changing a value in the web.config file causes the store to be re-created.. are there other things that do this?)
Is there a better way to do this?
Web.config causes the application to restart, and it is that action which is clearing out HttpContext.Current.Application.
Anything that restarts the application, touching web.config, manually doing it in IIS, having the application pool recycled by IIS will "clear" that data.
With that in mind it is still the most pernament in-memory store available, so if you need something more pernament you will have to persist your data to disk or to a database somewhere.
You probably don't really need to use it though (we rarely do), usually the best tactic is to use the application cache and rebuild resources as required. As long as your server isnt under high memory stress then cache will not be dropped either (unelss an expiry is set).
My understanding this is available for the application lifetime, or until the application pool is reset.
There is a good article here on all the various reasons the application/session pool in IIS would be recycled.
There are settings in both IIS and also web.config which can change the behavior of the application store availability.