A problem with our application is that it stores "work" variables into the Session and also on the form in an attempt to improve performance/laziness. This is ingrained into the application.
We have a problem where this data is lost after a deployment and the end user must refresh the page or they receive exceptions.
I am looking at changing our Session State from In process to a State Server. We have multiple instances of our web application running for different users.
My question is, is the State Server data separate or will there be a potential to mix between instances? Our admin users may log into multiple instances but typically clients only log into the instance they are primarily running on.
In- Proc: Session state is stored locally in the memory of the ASP.NET worker process.
StateServer: Session state is stored outside of the ASP.NET worker process and is managed by a Windows service. The location of this service is specified by stateConnectionString attribute.
SQLServer: Session state is stored outside of the ASP.NET worker process in a SQL Server database. The location of this database is specified using the sqlConnectionString attribute.
You can use StateServer or SQLServer to share the session between two instances.
You could refer to the below link for more detail:
Sharing sessions across applications using the ASP.NET Session State Service
https://stackoverflow.com/a/36145075
https://learn.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525037(v=vs.90)
Related
I have written one .Net Application recently which is deployed on IIS. The application is collecting timely data from the data server. Application internally use multiple HTTP connection and application-level caching to improve the application performance.
The recycling is configured with one day interval. I have noticed that whenever IIS manager recycled the service, the newer application does not have any cache data. I have two questions related to this.
Is the case, whenever application get recycled it will not have any cache data which are used on previous instance?
On application recycle, will it release all the HTTP connection which are present on the application.
Also, is there any way to preserve the application state to newly created instance after recycling process happens?
Please let me if any questions are ambiguous.
I read from MSDN site that ASP session state is process dependent and the actions that affect the process also affect session state, where as ASP.Net session state is process independent. Also I have read that since ASP.Net follows out-of-process model it supports server farm configurations.
I tried to search and figure out what they mean by process but out of luck
What is exactly meant by Process in that definition?
An example would be helpful for me to understand it better
That means if you are using InProc session state then it will be dependent on your apppool. If apppool resets you will loose session. So, to avoid this you can use State server or Sql server mode of session state.
In a server farm configuration, you have multiple machines serving the single website. When you use InProc sessions in a server farm, then every server has it's own independent Session state.
When you use stateserver or sqlserver as session store, then session state is stored in a separate server, outside of the webserver process. This store is accessed by all webservers, which means they share the session state.
I work with Session[""] objects in ASP .NET/C# MVC. I do a lot of checking on them, but I ask myself, what can destroy a session object without I specify it ?
I want to be sure that these Session[""] will be intact during some processes and can be only cleared by my instructions or if the user quit the application.
If you're using InProc, then a number of things can kill a sessions state. e.g.
Timeout (this can be set in config)
AppPool recycle
Web.Config change
Server crash
If you need a more durable solution, have a read of this article, and there's a few alternatives in this article too.
It's dependent on the type of session state you use.
InProc - sessions are destroyed if the web server process shuts down or crashes. The default shutdown time is 20 minutes after the IIS Application Pool is in active. If the IIS Application pool hits its memory limits it will also shutdown, so this is the least recommended approach for session state management.
StateServer - sessions are stored in a separate service on a server. The session will stay active until this service shuts down or is unavailable. It's more reliable than InProc, but if the service shuts down you loose any session data.
SQLServer - sessions are stored in a SQL database. This is the most robust solution and sessions are essentially guaranteed until you destroy them, but it's also the most complex to set up, requiring SQL server and a database.
Custom - Some other method of storing sessions that you would have to specify.
More information on the subject can be found in the links below.
http://msdn.microsoft.com/en-us/library/vstudio/ms178581%28v=vs.100%29.aspx
http://msdn.microsoft.com/en-us/library/vstudio/system.web.sessionstate.sessionstatemode%28v=vs.100%29.aspx
I had To move a pre built asp website from single worker process environment to multiple worker process environment on cloud servers.
I was having a class with static arraylist variable which use to contain last 2 minutes of all session information for tracking purpose. The admin use to access this arraylist to view live reports. But on moving it to cloud infrastructure this has breaked down results are no longer correct. It depends on which server behind load balancer is serving the pages thus we have multiple instances of the static variable per app pool. I tried to move to mysql but we needed to flush out data regularly and it was also having performance issue. Here the arraylist is processed heavily to churn out useful data thus I need something which is inmemory.
Please note that before also the use of static variable without lock was the downside but that only led to difference between 1 or 2 records but was blazing fast.
You can consider backing your session by SQL server based session storage.
Alternatively you can use a application caching server to back it. That will let you share it across multiple web servers.
i am having problems with an asp.net c# site whereby i am setting a session state object to true and then redirecting to another page that needs to check the value of the session state object and it is null.
Sometimes it is set correctly and other times is is simply null.
When i debug on my local machine it works perfectly every time. Only when i upload to my web server does this temperamental behaviour happen.
As it is based around the security of the site it is obviously important that the session data be valid and accurate every time.
Is session state data unreliable?
AFAIK its set to inproc, cookieless, 30 min timeout, vanilla installation of IIS.
Does anyone have any suggestions? Perhaps i need to thread.sleep inbetween the storing of the session data and the reading?
NB: the time between the write and the read is about 70ms.. ample time for the data to be written to RAM.....
No. It sounds like you are misusing session state. You can not rely on the user's session to be there. Your ASP.NET worker process could recycle, restarting the application and killing all sessions, or a file could change in your website, causing your application to restart and flushing all sessions, cookies could get flushed on the client, timeouts could happen, etc.
So you have to provide for all of these scenarios with Session State. Try to avoid using session state for things like this. If you're setting access inside your session state and you don't know exactly how it works, you could be opening your site up for a lot of security risks.
Everything point to a web farm. If you have different web servers on the production environment serving your application you would experiment this behavior.
I don't find any other explanation for this "WORKS ON MY MACHINE!"
I don't have an answer for your particular problem, but Claudio my be on to something.
What I have to say is that using session for security is so 90's. Literally.
FormsAuthentication was developed to replace that technique and does quite a fine job.
You should only rely upon session for trivial concerns that are easily recoverable.
Security is not one of those.
If the session state is lost, typically that's because your process either recycles or fails. I would never "rely" on the session state between pages. Instead you might want to try to persist data between pages some other way. Perhaps passing the information via form variables or saving the data in the database.
ASP.NET Profiles are a preferred way to save this sort of information. You might want to read ASP.NET State Management Recommendations.