How Can I persist a User-Specific data for an ASP.Net application.
I tried Session Variable - Not good when the worker process recycles.
I need something that can be accessed GLOBALLY by any class of my application.
Advice most welcome.
I tried to utilize asp.net session State Server but I got some DLLs crashing because they are Unserializable.
Is there any other way to have a persistent variable across the application?
ASP.NET session state can be configured to persist to a database.
Here is a tutorial on how to set that up.
Store Data in a Database (such as SQL Server).
You should use Session. You can access session state globally in a class like this...
HttpContext.Current.Session
To avoid losing sessions by the worker process recycling, use StateServer mode.
You can change the Session State Server to not be in process which will make it far more stable and also seperate it from the worker process (You'll need to be able to start the Asp.NET State Service on the server if it's not already running)
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"/>
Also if you need to share it across applications in the same domain you should be able to give them the same machine key
Theres nothing you can really do about the process recycling. If you use the Cache smartly to retain information in a more global sense but you still have the same worker process limitation.
I try and design my app in a n-tier setup with business entity objects. The factory methods for my objects use the cache kind of like a lazy instantation pattern. If its in the cahce, pull it. If not, put it into the cache for next time.
i.e
MyAppsNameSpace.MyBusinessLayerNameSpace.MyObject.GetObject(objectID)
now when this returns my object, it may be from the cache or may not, if the object is under high usage then it will be probably be cached.
This can be used throughout your entire app and because the caching mechanism is maintained centrally you dont really have to worry about it.
You could use the Profile Provider with a SQL database as your backing store.
See this MSDN Article
If you lose data when the worker process recycles then you should stop using the InProc persistance mode for the Session. Use StateServer or SQL Server. Ultimately you could build your own session persistance module if neither satisfies you.
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.
In-Proc session mode does not work in Windows Azure.Could you please reply the useful example?
Use an external session state provider. Here is an example using Redis Cache: https://msdn.microsoft.com/library/azure/dn690522.aspx
If I understand correctly, you want to do session management and handle the session timeout property. There are various ways to do session management in Azure, one of them (and usually, the preferred one) is to do it using Redis Cache.
There is a Nuget package which you can directly add to your project (RedisSessionStateProvider). Once this is done, you need to add a few tweaks to your web.config, and within that you set the timeout. This is what I had done in my project (setting as 1 for test):
<sessionState mode="Custom" customProvider="MySessionStateStore" timeout="1">
You can set your custom timeout right here.
If you want to delve deeper, more details on this session state provider is available at: https://msdn.microsoft.com/en-us/library/azure/dn690522.aspx
Hope this helps.
I am working on a MVC 3 application that will be hosted in a web-farm with a multi-worker process setup. There are about a dozen variables that are being stored in Session but are getting lost due to the IIS setup.
By getting lost I mean that when the Logon process succeeds I see through logging that I have set the Session variables but then after the Redirect action and on the landing Controller Action the Session variables are often empty. I'm not sure if this is related but this is in a HTTPS.
We are looking at the possibility of moving our user-specific settings that are stored in Session out to some other mechanism but there is one variable that I won't be able to do that with. Given the above deployment environment I have the following questions.
Are cookies my only (best?) alternative to storing Session variables for user-specific settings?
If so is there a secure mechanism for writing cookies so they cannot be manipulated and can still be read in a multi-server environment?
As I understand it System.Runtime.Caching suffers from the same problem when ran in the above IIS configuration. Is that true?
Are cookies my only (best?) alternative to storing Session variables
for user-specific settings?
No - they are about the worst possible approach. Three reasons that come to mind:
They can be manipulated.
They travel with every request from client to server - inefficient.
They will add more complications to your implementation since you'll have to start thinking about securing them in different ways.
If so is there a secure mechanism for writing cookies so they cannot
be manipulated and can still be read in a multi-server environment?
See answer above.
As I understand it System.Runtime.Caching suffers from the same
problem when ran in the above IIS configuration. Is that true?
True. You should be using any of the State Providers that are out of proc. You can either use Sql Server to store session data -provided your objects are serializable, obviously- or the State server mode mode="stateserver"
Read here for more details
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.
A website that I'm working on is making extensive use of the HttpContext.Current.Application store to cache lookup data from the database. (This isn't a lot of data - just simple things that are used in drop down lists etc..)
A few questions about this approach:
Does this store have a lifetime (in the same way that a user's session will time-out after 20 minutes, does the application store timeout)?
Do events in IIS or events in the same App Domain as the website cause the Application store to refresh? (I understand that changing a value in the web.config file causes the store to be re-created.. are there other things that do this?)
Is there a better way to do this?
Web.config causes the application to restart, and it is that action which is clearing out HttpContext.Current.Application.
Anything that restarts the application, touching web.config, manually doing it in IIS, having the application pool recycled by IIS will "clear" that data.
With that in mind it is still the most pernament in-memory store available, so if you need something more pernament you will have to persist your data to disk or to a database somewhere.
You probably don't really need to use it though (we rarely do), usually the best tactic is to use the application cache and rebuild resources as required. As long as your server isnt under high memory stress then cache will not be dropped either (unelss an expiry is set).
My understanding this is available for the application lifetime, or until the application pool is reset.
There is a good article here on all the various reasons the application/session pool in IIS would be recycled.
There are settings in both IIS and also web.config which can change the behavior of the application store availability.