I'm using ASP.NET 5 Session in StateServer mode with a session state service running on a different machine. When all is working fine in the app, certain session objects are able to be accessed from the Session. However, when I restart the app, it appears that the user's session still exists, but certain objects throw an (de)serialization error when trying to get them from session. This leads me to believe that most of the time the session data is getting pulled from a local cache that doesn't serialize/deserialize the objects like the StateServer does... and then when the app restarts the local cache is lost, and so the objects have to get pulled from the StateServer, which then has problems deserializaing certain objects.
Can anyone confirm my hunch about Session caching when using StateServer mode in asp.net 5?
EDIT: I think I found the answer here:
I was actually surprised to see the behavior exactly the same as with
InProc objects. Even though objects serialize ASP. Net tracks objects
locally and writes out any changes out to the stateserver.
Related
I have two ASP.NET applications using Forms Authentication and Single Sign On and I would like to persist Session variables between them.
Upon testing, I cant seem to get the Session variables to be read from the other application. Both apps are on the same domain (app1.domain.com & app2.domain.com) and I have set up my config (a.f.a.i.k.) correctly to reflect this.
I have noticed that when testing on the release server the session id is different even when using tab pages on the same browser (I thought they would be the same!), yet debugging on my local IIS the session id is the same (and I still cant read session variables across sub-domains).
Anyone got any pointers to what I may have missed?
Best Regards
By default, SessionState mode is InProc which means Session State data is stored in each AppDomain's memory. AppDomains are isolated, and they do not share SessionState.
You need SQLServer or StateServer as SessionState mode.
The above simplifies my situation, but highlights my dilemma -- occasionally my users are unable to access their session variables (well before the session timeout). My configuration is as follows:
Application is .NET Framework 3.5
Session State is handled by StateServer (running locally on web server)
StateServer service running on the web server is .NET Framework 4.0
There is only one web server, it is not a farm or garden situation
I have a page in the flow of control that sets a session variable to an instance of a custom user object (If I binary serialize the objects to the filesystem, their size can be between 6kb and 30kb, so not small, but not very large either). The application usually only has as many as 10 simultaneous users max. Subsequent pages in the flow of control, check that the session variable is not null. If the session variable is null, it is assumed that the session has timed out and the user is redirected to a "lost session" page. I have placed (for debugging purposes) another check on that same session object in the lost session page.
What I'm seeing in the logs is very strange -- users are being sent to the lost session page, but the object does indeed exist in the session! Is it possible that the session variable be null on PageTwo.aspx but not null on LostSession.aspx? Is it possible that PageTwo.aspx is run too soon -- meaning the object has not yet been fully "written" to the Session StateServer?
Any ideas on how I can debug this further?
Because the user object exists in LostSession it should also exist in PageTwo. Since you use redirect there should be no problems with data being accessed too soon.
You could try to set a checkpoint on in PageTwo on the line where the user object is being assigned and look into the session object manually. Comparing it with PageOne and LostSession might give you a clue what causes your issue.
It is possible that the key contains a typo and thus the user object is set to null, because the key referenced has no object in the session.
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.
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