We Keep Coding

What happens when application pool re-cycles in ASP.NET MVC?

I was using Session heavily for storing data of posted requests from client side on server. On research, various answers over stackoverflow pointing me , Not to use Session in ASP.NET MVC. Main reason is : Application Pool recycles frequently during life time of production server and this causes Session to recycle as well.
Thatswhy I am thinking to replace session objects with de-serialize able string "....".
My whole concern is : This singleton object containing this string (de-serialize able into Objects ) must not corrupt/recycle or re-initialize on app pool re-cycle.
So my final question would be : What happens on app pool-recycle? Only Session re-cycles ? Or the whole memory re-cycles and re-initializes?
My target web server : Microsoft ASP.NET with MVC

When the application recycles, the windows process the site is running in w3wp.exe ends and a new one is created. It's also possible a site has multiple worker processes for one application pool. In that case they all end and 1 spins up, and new worker processes will be created as they are needed.
When this happens, anything the website code was storing in memory is lost. This includes In Process Session information.
However .Net Session State can work in two modes, in process, or database. You can run the aspnet_regsql tool to create a database in sql server for storing session information. Then you can change the web.config to have session run in the database. You can use the same session apis, they work the same in both modes. But putting it in database mode causes it to persist everything to the database instead of in process memory. Then when AppPool recycles, you lose nothing.
RegSql Doc: https://msdn.microsoft.com/library/ms229862(v=vs.100).aspx
A well designed ASP.Net Site (be it MVC, Web Forms, WebApi(1/2)) etc. should be designed to be able to fully recover from any recycles. A site recycle should not break your web site.

Recycling the Application Pool will blow away your AppDomain and everything in it, including all static values.
This is why it loses session state in the first place.
You probably want a database.

SLaks pretty much answered your question. Here is the solution -
In ASP.Net MVC, we do not use Session State like Web Form.
However, you can still use Session State, but you want to use external Session State provider instead of default InProc mode - values and variables are stored in memory on the local Web server.
You have few options -
StateServer
SQLServer
Custom mode using Redis Cache like Azure.

How to update asp net webforms or mvc application without losing session?

Here is my scenario.
I publish my webforms or mvc application on iis 8 on windows server 2012.
Then my customer requests something else and I have to update codebehind.
For example a new input on form or a new column on db. And I am using session variables for membership or shop cart processes.
When I copy the new bin file in server,(when I publish my app), the session dies. How can I solve this update problem?
What shall I do to keep session alive? Because Visitors are losing their shopping carts.
Thanks for help.

A number of things will cause IIS to drop a session:
Lots of files update and ASP.NET proactively recompiles for you.
The session times out naturally
Updating the web.config which would cause it to
recycle
The site app pool recycles for another reason
It sounds like you are falling afoul of the first, and there's no way to prevent that behavior.
It sounds like you are using "In Process" Session, which is the default, which is why you are losing the baskets etc.
From MSDN:
InProc mode, which stores session state in memory on the Web server. This is the default.
The other options are:
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.
Switching session to any of these others would enable you to update, but migration isn't instant.

When I copy the new bin file in server,(when I publish my app), the
session dies. How can I solve this update problem? What shall I do to
keep session alive?
By default, Session-State Mode is InProc. You want to use either StateServer or SQLServer.
In Windows Azure, we use Custom mode and store in Redis Cache.
Because Visitors are losing their shopping carts.
Even then, Session State is not reliable.
I normally create a Shopping Cart table in database. Then save the Id of the shopping cart inside cookie on the client browser.
In addition, if user logins, I also save the UserId in the same table, so user can still view his/her shopping cart at any computer.
For example, amazon.com has similar approach.

MVC 5 Keep User logged when browser is restarted

First of all, I'm new to MVC, but I managed to create a simple custom login using Entity Framework, MVC 5 and C#. ( I do not want to use Identity because the idea is to get to know the functions behind it).
I'm currently doing this with Session Variables, so when the user exist in the DB, I store the info like Role, Name, etc. in Session Variables, but when the user closes the browser or I restart the app the session is lost so the user has to login again, how can I prevent that from happening and keep the user logged like Identity does?

There seems to be some confusion about how authentication and sessions actually work here.
First, sessions utilize cookies. That's how they work. A cookie is set with the session identifier so that the server can retrieve the appropriate session with each subsequent request. The only alternative is what's referred to as "cookie-less sessions", where the session identifier is passed around as a query string parameter. However, these are generally discouraged because inevitably the URL leaks and its far too easy to hijack user sessions this way.
Second, sessions on the server are not the same thing as a browser "session". The server-side session does not expire when you close your browser. That's just patently false. You can however, have the cookie containing the session identifier be set as a "session cookie", which causes the cookie itself to expire when the browser session ends. The server session still exists, only without the cookie, there's no way to look it up. However, you can just as easily have the cookie expire after a period of days or weeks. The fact that it's a cookie used to maintain a session doesn't necessitate that it be a "session cookie".
Third, there's different mechanisms of session storage. The default, because it requires no configuration, is what's called "in-proc". That means the session data is stored in memory by the web server process. When the web server process is terminated, its memory block is freed, along with your session data. Persistent sessions require persistent storage, meaning something like a database.
Long and short, there's nothing wrong with what you're doing, you just don't have your sessions configured properly. Refer to the MSDN docs on the <sessionState> Web.config element. You'll need to add something similar to:
<sessionState mode="SQLServer"
cookieless="false"
timeout="3600"
sqlConnectionString="[Connection String Here]" />

Where is the Session stored?

I ask to my friend, where is session stored? At Server or Browser?
He said, at the server.
Then I said "I think things saved at server called cache".
Then, I go to google search reading article, but I found no specific correct answer, at MSDN too, no specific answer.

Usually it is saved in the server's memory, but you can also have a database backed cache. It is never cached on the client, since it can contain information that shouldn't be available to the user, like the password to your database.
The full list of places where you can save the session state can be found on 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.

Session itself is stored on the server side.Each browser accessing the server will get from the server unique Session ID. This Session ID browser sends to each page requested to the same server.
Session
So on client (browser) side, only Session ID is stored in the browser cookie.
(this is default behavior, when session cookies are enabled in the browser settings... there is also a technique called "URL rewriting" to embed Session ID as URL query parameter, each time the server is called, enabling the application to work even if browser session cookies are disabled)
For more information go through this http://ejvyas.blogspot.in/2010/02/where-is-stored-is-it-in-browser-or-at.html

Quick answer: on both sides.
Previously, the session was stored on a server side. This approach implies that you have to go to a server side each time you create or validate session. The session also have to be replicated for all the web-servers. These things can sufficiently harm the performance.
The another one oldschool way to store the session data as a cookie (as it is mentioned in answers). The obvious flow is that cookies has 4kb limit.
In order to overcome it, the World Wide Web Consortium defined the client side sessionStorage, that can be instantly added or validated and does not demand to replicate the data between web-servers.
It can be seen in browser's Dev Tools / Application tab. For example, this is how the session for my Facebook page looks like:

Avoiding loss of session variables when web.config and bin folder changes

We have a ASP.net website and I use session variables. But when customer was using my website, If i change the web.config then it causes application pool to restart and all sessions gets lost.
Now in my case the website is for submitting query from customers. So the data from customer will be written to our database once he submits the page or form. Now all the information like customer number ,name etc will be lost and only his query(which is not a session variable) will be submitted. So we get only query and no information related who has posted it. So it becomes a serious problem for us to find who has posted it.
Also if I change the bin folder files then does it cause the same problem?
So what are the best solutions for this problem?

Yes, it is expected behavior for in-memory session state - restarts of IIS or recycle of application pool or recycle of app domain will kill the state. I.e. changing web.config or touching enough files in the site (including bin folder) will lead to app-domain recycle by built in ASP.Net logic.
To solve it use out-of-process ASP.Net SQL session state: build in SQL session state or state service, there are also many other implementation of session state for ASP.Net.