We have an MVC web app that uses FormsAuthentication and also stores a couple of variables in Session variables. We've encountered a few situations lately where the session variables are lost, but the user is still logged in. A quick Google lead me to a few SO articles mentioning that In Proc Session State is regularly lost and that if we require it to persist, we should consider moving to a non In Proc solution.
Coming from a classic ASP background, where we relied on Session state for the lifetime of the session, it seems a bit baffling that I now can't rely on it at all. Surely In Proc Session State is of no value to anyone if it can be lost at the drop of a hat? Am I missing something?
I realise that storing it in an SQL server has it's benefits, but for small webapps with little traffic, In Proc is an ideal solution, could it be relied upon.
ASP.NET session state is able to run in a separate process from the ASP.NET host process. If session state is in a separate process, the ASP.NET process can come and go while the session state process remains available. Of course, you can still use session state in process similar to classic ASP, too.
You don’t have to use SQL server to store session data in out of process, you can use out of process state server which can be in memory on the same server as the web server.
You can read more about how to configure out of process session state under http://msdn.microsoft.com/en-us/library/ms972429.aspx
As far as i know in-proc sessions state is lost after recompiling application and recycling application pool. App pool could be recycled if there is not enough memory or it's have regular restart time interval.
Related
In this question there's a comment with a few upvotes that states:
InProc session state is known to be highly unstable under load. If it's abused (happens all the time), then Session["foo"] = null will perform better than Session.Remove["foo"]. The garbage collector should clean up the mess of excessive session variables
This concerns me as all of my web apps make heavy use of session state (account info, baskets, payment details, user preferences etc.).
I can't seem to find any evidence to back up this claim, can someone debunk this or explain why this is correct. Am I wrong to be storing such info in session? I'm not looking for a pros and cons of InProc vs SQL, I'm aware of the differences.
All of my apps run on a single or dedicated webserver so I've never seen any benefit or point in moving to SQL for session state.
InProc Session State is stable and you don't have to worry about it. I don't know why he called it unstable but I guess he might have thought one of the following reasons while commenting:
If your application gets too much load; when you scale it, you have to use sticky session (for InProc SessionState) to redirect the requests to the same server for a client otherwise session object would not persist.
If an application has memory leaks or inconsistencies, heavy load will most probably trigger the application to reset and this will cause all the session data be lost so that current users' active pages might get errors since their session datas are lost.
Session object is locked out for the entire request (for that user only) to prevent multiple pages to write into the session so that if concurrent requests are made for example, they have to wait for each other to write data into Session. But it happens both in SQL and InProc SessionState.
I saw banking applications which work with InProc SessionState and there is nothing unstable about it.
The ASP.NET SQL SessionState provider seems excessive for my requirements. SQL Server has to be 'configured' to support it and I have questions about how optimized it is (i.e. is there one db hit to fetch the whole session or one for every session item requested?).
I think I could implement a custom solution very easily that I would understand and easily redeploy to other projects. Is there something fundamental I haven't considered here and an obvious reason why the built in SessionState handler is the 'best' way to go?
Just to clarify, our applications run on single servers at the moment. My main motivation for doing this is to enable Session to persist across IIS restarts and therefore provide more reliability for users.
you could use StateServer mode.
StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool.
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.
more info at http://msdn.microsoft.com/en-us/library/ms178586.aspx
It takes just minutes to setup SQL session state server (assuming you have SQL server already running). I can't imagine that you can write anything in less time than it would take to at least try out what already exists and is free and supported by MS.
A proven, built-in/off-the-shelf solution is always better place to start than custom. You may still end up with a custom solution, but don't pick it because you didn't bother to test what is already available to you.
Are there any pre-conditions before storing any objects in session state.
I mean when will I not be able to insert an object in session state.
This was an interview question that was asked to me.
What could be the possible reason for not being able to store an object in session state?
Here are some that should be considered:
If it has more session data, then more memory is consumed on the web server, and that can affect performance.
It won't work in web garden mode, because in that mode multiple aspnet_wp.exe will be running on the same machine.
And if the appdomain or worker process (aspnet_wp.exe) restart/recycles very often then its not a good idea to use it
and it is gathered from here ... hope it answer your query ...
There are places in the asp.net page request life-cycle that you do not have access to the session state yet due to the lack of a valid user session such as Application_Authorize where we do not have an authenticated user yet, so Session will be null. The actual implementation of the Session store shouldn't really be a concern, neither should how the data is serialized.
I deployed an ASP.net web site to two servers and put them behind the load balanced environment. Now that problem is that the performance is really slow. Even for just simple button event, it takes long time to finish the simple button event. However, if I access the site separately (by its server’s address), performance is good. What our system engineer told me was that the application handles session state in process as if it runs on only one server, it could not handle clustering. So, he suggested that I should use the session object in the code to store the session in SQL server, or cookie.
I am currently using session variables to store the session.
I am kind of a new to ASP.net and I am not sure exactly what this mean and how I can accomplish this in my .net code (C#)?
Thanks.
Here is a good link to start you off: ASP.NET Session State
You would probably want to go with the Out of process mode where the servers all access 1 session process on a designated server, if speed is your top priority or SQL Server mode where all servers access 1 database if reliability is your top priority as with out of process mode if the process dies your session data is lost similar to how in-process session handling works.
No coding changes for storing session data would be needed, just the initial configuration of the environment and a web.config change.
First off, you need to configure sessionstate in your web.config for what you want to do. Here is a step by step tutorial on storing sessionstate in sql server. Hope it helps!
http://support.microsoft.com/kb/317604
I have an iframe keep alive (iframe that hits a page, defibrillator.aspx, on my site every few minutes to keep the session alive) on my masterpage for an asp.net app. This works most of the time but every so often my session variables return null during the page load on my defibrillator page. At first, I thought the session was being timed out by the server for some reason so I put some logging into the Session_End event in the global.asax but it was never hit.
Any ideas what could cause the session to be lost.
Many things can cause session to be lost. An AppPool recycle, iisreset, the client could lose its session cookie, etc. Without knowing more it is difficult to tell what is the problem.
If session is so critical that you poll the application to keep the worker process from sleeping perhaps you ought to look into persisting your session state to SQL Server.
Peter Bromberg outlines the primary reasons for ASP.NET session timeouts on his blog.
I had this same sort of problem, storing a shopping cart state in Session but having it randomly return null instead. I think I found the answer on Bertrand Le Roy's blog, which seems to work for me:
Session loss problems can also result
from a misconfigured application pool.
For example, if the application pool
your site is running is configured as
a web farm or a web garden (by setting
the maximum number of worker processes
to more than one), and if you're not
using the session service or SQL
sessions, incoming requests will
unpredictably go to one of the worker
processes, and if it's not the one the
session was created on, it's lost. The
solutions to this problem is either
not to use a web garden if you don't
need the performance boost, or use one
of the out of process session
providers.
Blog
If the chosen persistence mechanism is InProc then it can be triggered by many things. Totally counter-recommended for a production environment.