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.
Related
I was trying to create an asp.net application with session state as out proc. (State server). When following the steps given in this article it was mentioned as we require to set the sessionstate in our IIS and we need to start an asp.net state service in our service management. My question is, if i change in IIS will it not affect the session handling of other applications? what if i have 2 applications and i want only one application to have session mode as out proc and other as inproc.. in this case changing in iis will require other applications hosted in that iis to follow out proc mode of session handling?
Please let me understand this in detail. Please let me know if further information required on this if any.
Which version of IIS are you using? If it is on Windows Server 2008 R2 or greater Session state is configurable on a per application basis(the configuration is actually stored in the application's web.config file).
Rather than going to Session state at the root website node as they have done in your link expand out so you can see the application you want to change, select it and then select Session state and select the session storage you want the application to use.
The default Session setting is InProc for .Net applications so I suggest changing the one you want to use the State Server.
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.
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.
I have an asp.net application in which i redirect from one page to another. I'm validating the SessionID in the second page to make sure both requests are of the same session. Now, my problem is the SessionID changes whenever a Postback is happened.
Now, I added the Session tag into my web.config
<sessionState mode="InProc" cookieless="true"/>
Now, the problem with the session was solved and a new issue started appearing. Whenever i make a call with Cookiless="true" in my web.config file, my URL shows a junk address
http://localhost:10766/(S(ojbcobj0aw0wiosttgpknwby))/registration.aspx
If I remove the Cookieless tag the session will be lost in the next page?
Do anyone know why is this coming and if any fix is there for this problem?
I went through lot of threads but i couldn't find a proper fix for this.
EDITED:
I Set my cookieless="false" and now its working fine.
.NET Framework has 05 (five) 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.
Now i need to know exactly what does your application do to recommend the better solution:
Do you store something in Session?
Are you using multithreading?
How many servers your farm will have (when the application go live)
Does your app connect to database?
If you keep your original web.config, by default your application will use InProc mode and will store session id on cookie, unless your browser or local server denied it.
I'm waiting to the answers to complement my post.
Reference:
http://msdn.microsoft.com/en-us/library/ms178586.ASPX
I have a website in C#/ASP.NET that is currently in development. When we are in production, I would like to do releases frequently over the course of the day, as we fix bugs and add features (like this: http://toni.org/2010/05/19/in-praise-of-continuous-deployment-the-wordpress-com-story/).
If you upload a new version of the site or even change a single file, it kicks out the users that are currently logged in and makes them start over any forms and such. Is there a secret to being able to do deployments without interfering with users for .NET sites?
If you make a change to a config file, the contents of a bin folder of the app, or things like that, the ASP.NET worker process restarts along with your application.
This results in deleted sessions and kicked-out users.
The solution is to use other session storage methods other than the default InProc.
You can achieve this by setting the session state mode. The SqlServer and StateServer options provide very good remedy for your issue.
SqlServer mode is relatively easy to set up and get up and running. (Basically, it's just creating a database, running aspnet_regsql, and then specifying it to the config.) If you don't have MS SQL Server or don't want to use it, you can use StateServer, or create your own provider and use the Custom mode.
The only restriction is that you can only store serializable values with SqlServer and StateServer mode.
The reason you're seeing this is because you are resetting the application pool, thus resetting everyone's session.
The cleanest route would be to offload your session to a session state server, or minimize your use of session.
One way around this is if you can't offload your session is to always deploy to a new virtual directory. Your public facing URL then just redirects to your latest version. All users that are already logged in would continue to use the older version, but any new users would use the new version.
There are two alternatives to achieve that:
Do not use Session at all. (You may use cookies for authentication)
Use another Session-state mode. State server or SQLServer. http://msdn.microsoft.com/en-us/library/ms178586(v=VS.80).aspx
Either way you will also gain the flexibility to be able to run your application on multiple servers for performance or fail safe clustering.
Depending on what you store in the Session object, you may be able to reconstruct it in Global.asax's Session_Start handler. I used to do this in an internal application where we only really stored the user's identity in the Session, so we could just use their authorization cookie to recreate the session.
One thing to keep in mind if you do this: say a user loads up a form and then leaves for lunch, and you update that page while they are away. If they return to their desk and submit the form they'll be submitting the old version of the form to the new code-behind.
I suppose users are kicked because web-server application process is restarted. By default user sessions are stored in memory and session data is killed. Session provider is configurable option in web.config. May be choosing external (out-of-web-application-process) session provider is a step toward what you are expecting.