We are thinking for moving our sessions from memory to sql server (using web.config session mode setting).
Will it work the same way as it does with in memory or our users will be able to retain their session even if the application recycles? What about cache?
Session State Service or Sql Server mode retains session values if the web application restarts. Cache will be removed if the web application restarts.
Sql Server mode stores session data in sql server database (persistent).
State Service stores session data in memory, on a separate (possibly remote) process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool.
Cache is stored in ASP.NET worker process memory.
Related
I'm working on an ASP.net 4 web application using MVC5. I'm curious as to where sessions are stored in the default application scaffold running locally and whether there's any configuration available.
The session is configured on web.config. By default is saved on memory and a service that runs on server is handle that. Other way is to save it on a database...
This is the Session-State Modes... from MSDN:
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Custom mode, which enables you to specify a custom storage provider.
Off mode, which disables session state.
We're currently deploying code to live pretty reguarly at the moment, but the down side is destroying user session data.
Is there a way of being able to recycle IIS without loosing session data, or is persisiting session state in SQL server or alike the only way?
In-memory session state is stored in the memory of the IIS worker process. When you restart the application pool you are effectively stopping and restarting the worker process, so whatever state is held by the worker process, including all session objects, is lost.
So, yes, you need store session data outside the IIS worker process, such as in SQL, in order to not "destroy" users' session data.
Ok I'm sure this is pretty obvious. But when you say session state is persisted on the "server" in memory, are we talking about IIS or what? When I think of Server-side session State, I think memory in terms of IIS app pools and such. Am I off base or missing anything here?
http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx
the term "server" could mean many things. Sure it's "server-side" but what specific process / memory / area / app on the server are we talking about (IIS only? other?)
I wish MS would have explained what they mean because that's pretty relative.
Specifically this, "store on server"
Storing Data on the Server (in memory)
• Session state
• Application state
• Profile Properties
so "on the server" where in memory and what process/app is handling each of these?
" Sure it's "server-side" but what specific process / memory / area / app on the server are we talking about (IIS only? other?)"
Each site runs in an application pool and each application pool is basically a process on your web server. If your session is configured to be in process, your session objects will be stored in that process' memory
It depends. By default it's in the worker process memory, but it can be on a dedicated state server or in SQL or your own custom provider.
From MSDN:
ASP.NET session state supports several different storage options for session data. Each option is identified by a value in the SessionStateMode enumeration. The following list describes the available session state modes:
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Custom mode, which enables you to specify a custom storage provider.
Off mode, which disables session state.
ASP.NET is just a framework; it's a collection of classes, and they execute code. It's this code that provides you with session state, and it stores the information about your session state in some objects, just like a dictionary or similar.
(When doing In Proc, then you have state server, sql server, and custom, where custom can be anything as long as someone has written some code implementing the right interfaces)
How would one go about making sure the InProc session memory gets stored in a DB so it's possible to restart the web-server without losing sessions?
Have a look at http://msdn.microsoft.com/en-us/library/ms178586.aspx
Change SessionMode from "InProc" to "SQLServer" and insert the connectionstring to the sqlserver.
Edit after your comment:
Using this mode ensures that session
state is preserved if the Web
application is restarted and also
makes session state available to
multiple Web servers in a Web farm.
I can store Session State in "InProc" or State Server or Sql Server. If i maintain
Application State where do objects are getting physically stored?
Application state is stored in memory. Every time the application is restarted, this is cleared out.
Because it is in memory, it cannot be used to store data accessible to a web farm.
it is stored in memory on the server
MSDN