I need to store user preferences on a per page basis in my application. For example, several pages use a custom grid pager control that needs to keep its current page size between postbacks. Most of the settings don't need to persist once the user leaves the page, but in some situations they do need to be restored. Note: Session is disabled in this application and will not be used.
I did some reading on isolated storage and understand that it can be used to store these user settings. Obviously cookies have been around a long time and are a proven approach to this scenario, but what about isolated storage? Is it going to work for all browsers and in all environments? Are permissions a problem? Does it require configuring anything on the end-user's side? Just how widely used is it? Why should one use isolated storage in an application for the given example?
Thanks!
Obviously cookies have been around a
long time and are a proven approach to
this scenario, but what about isolated
storage? Is it going to work for all
browsers and in all environments?
Ah - .NET isolated storage is SERVER SIDE. Like a database. It is meant as a small way to store small amounts of data( ONE user, not all users, viewstate) on the side the .NET application runs (in asp.net case = the server).
As such it is totally irrelvant to your question.
Put the data in a database. I know of VERY few usages of isolated stoage for ASP.NET applications, it craetes a TON of long term problems. It is not meant for server side apps.
You can always use hidden form field variables on a per-page basis, as a way to keep track of that page's state.
This is my preference to a session state strategy to deal with the scenario of users having say 2 FireFox browser instances open to the same page. No need to deal with session state issues in that scenario.
Related
I have an MVC application, where one controller returns a View that have an iframe , controller also returns url that need to loaded.
I need that iframe to load legacy .aspx pages.
Now I want to share some data from MVC controller to that .aspx page via 'SESSION' or 'Request' object.
Is it possible ? Do I have any other alternative to share data securely (I don't want to pass as get parameters).
Since we are talking about two different applications, there are some options but none through SESSION
Your first issue is how to identify the same user. There are two options here.
Through the use of cookies, if both applications are in the same domain. You can store a session identifier there and it will be sent to both applications. A jwt token would do fine or any other session identifier
Through the use of a single sign on system. This would be more tricky to implement and there are a lot of oauth/openidconnect systems out there to choose from.
Now onto the session iteself. Since we are talking about two applications, you are going to need some kind of shared place to store the session values
The simplest form would be a shared database where you store the session values. It could be in memory tables in mssql to speed things up. On the downside, you should be careful to invalidate/update the values which would cost in queries
Some kind of distributed cache, like REDIS.
Warning - You might see suggestions to use session state store. This is to share SESSION between servers and not so easily between applications, so I wouldn't suggest that.
C# - ASP MVC - .NET 4.5 - Bootstrap - Razor
I have a form wizard (http://vadimg.com/twitter-bootstrap-wizard-example/examples/basic.html) that is used to setup a complex object (obj1). A property of obj1 is a List<obj2>. On one step of the wizard I want to add multiple obj2's to the list. Since obj2 is slightly complex as well, I thought I would use another wizard to help build it. Except I need to persist this List<obj2> on wizard 1, while I'm off in wizard 2 building another obj2.
My first thought was to use a session to hold the List<obj2>, I was just wondering if that's a good option, or if there would be a better one? The user may leave from Wizard1 to go to Wizard2 and come back multiple times.
There's no perfect answer here; each approach has trade-offs. But here are some options that I can think of (and these are independent of ASP.NET/C#)
Session (as you suggest)
This will store data in web server memory (by default). If you have a lot of users, this could be a problem.
You risk the information being lost when the user gets a new cookie/the session times out.
Potentially better performance that a db, depending again on the number of users
Database (as you mentioned)
Could cause more database traffic.
Can save information for user even if they close a browser, switch computer, the power goes out, etc.
Maybe a separate NoSQL database just for transient wizard data would be worth trying.
Cookie (store data on the user's computer)
Users can potentially tamper with/view the data
There is a limit on cookie size (4 KB each?)
Local storage (HTML5)
Similar to cookies
But not such a small limit
Not every browser supports it (may need polyfill)
Form/Post/Hidden/ViewState
You could just post the data and drag the information from response to response
But this gets really annoying with back buttons & timeouts
Lots of work, and again, the user can tamper with the information
I have a small web application that has multi-language support (en, de, it, fr, nl, sl, hr). This application is accessed constantly from a lot of users that use it for a short time (the time to fill their data to get an internet access code).
I have a problem with setting the culture similar to this thread:
InitializeCulture change language of domain
I know how to do it, it's just that I'm not sure which state-management to use. I wanted to ask for suggestions which method to use. Those are my thoughts:
Session - the easiest way and the more elegant, but it's server side and I have a lot of requests so I fear that the server can get too overloaded
Cookie - easy to implement and it's client side, but some users have cookies disabled in their browser
QueryString - not so easy to implement in this phase, but it's client side and can be easily tested because the application has only 3 forms (3 URLs to add query string parameters)
I'd like to hear your ideas and suggestions.
Thank you in advance!
Actual persistence store would actually depend upon the scope/life-time of culture selection. For example, if it's user specific selection that has to be persisted over sessions then you can use database or persistent cookie where cookie will remember for a machine and database will remember across machines. The retrieval (from database) will happen when it's needed - and the value can be cached into ASP.NET cache (will need different key per user) or session or view-state (if its single page application) etc.
You shouldn't worry too much about putting that into session if you are already using session state for something else. In such case, it doesn't really consume any significant memory. If you have log out function then you can explicitly clear the session state and release that little bit of memory. If you don't have log out functionality then you can use small value for session timeout.
We have a web application that is storing all the site data in HttpRuntime.Cache.
We now need to deploy the application across 2 load balanced web servers.
This being the case, each web server will have its own cache, which is not ideal because if a user requests data from webserver1 it will be cached, but there next request might go to webserver2, and the data that their previous request cached won't be available.
Is it possible to use a shared-cache provider to share the HttpRuntime.Cache between the two web servers or to replicate the cache between them, so that the same cache will be available on both web servers? If so, what can I do to solve this problem?
No, you can't share the built-in ASP.NET cache, but you could use something like memcached or AppFabric instead.
Nope, it's not possible. You have to use so called ditributed cache like Microsoft AppFabric Caching or very popupar open source product memcached.
It sounds from your question that you've got user data it the cache? In that case I'd be with Aliostad and say dont go there!
HttpRuntime cache should be used for static but regularly used items that come from the database, the main purpose should be preventing database hits that would otherwise occur on every request regardless of user... so things like options in a combobox or certian configuration settings
If you do genuinely need caching for user data, then as above Memcached, Appfabric or nvelocity
There are layers of caching suitable for different needs, having only 2 webservers suggests that you dont yet require the Distributed caching frameworks above.
What is the server load, and what is the limiting factor, CPU, RAM, Network Bandwith? On your DB or your webservers? Each of these indicates a different caching strategy.
Don't go there. Normally, cache being a static object, only lives in the AppDomain. Manually updating these is a world of pain and strongly advise against.
You can use a number of caching solutions that sit in front of your server for that kind of purpose.
I'm definitely not a fan of WebForms, I prefer in the .NET world ASP.NET MVC.
Regardless, I'm working on a small part of a very large legacy WebForms application.
I'm integrating Korzh.com's EasyQuery.NET. to allow end users to create their own SQL queries based on pre-defined models made user friendly with aliases.
This is relevant because Korzh's demo uses Global.asax for its model and
query class along with Session.
Because the legacy WebForms application is very large, Global.asax in not used
for page specific items.
My solution was to use private static instead. static works well in desktop
applications but seems at the very least likely to cause some grief in WebForms applications.
I've discovered that !IsPostBack is not too reliable and it seems to me that
in WebForms the best practice may be to use Session. The problem with
Session is that it seems to be passed to the client with the HTML and can grow
very large in kilobytes.
QUESTIONS:
Since static variables reside on the IIS server when used with WebForms, does every user of a WebForms application share the same static variable address space? (I think the answer is yes).
What are the best practices/guidelines for using/not using static variables
with ASP.NET WebForms applications?
Thank you.
Regards,
Gerry (Lowry)
P.S.: I could not find answers
via Google or searching SO.
In ASP.NET, static instances will live for the lifetime of the application, that being the web application itself, until it is recycled, or shutdown, e.g.:
public class Global : HttpApplication {
public static string MyString
}
Because of this, the static property is accessible for all requests made to the application. Not the place to be storing page-specific items. There are quite a few storage mechanisms available:
HttpRuntime.Cache and HttpContext.Cache, both point to the same cache instance, and items exist for the lifetime of the application (so has the same issues as static instances).
HttpContext.Items, a request specific collection of items. Each request made to the application will have its own collection of items.
HttpSessionState session, persisted for the length of the user visit, or whenever it times out. This can be configured 4 ways:
3.a. InProc, session objects are stored in memory by the worker process itself. Fast accessing cache, doesn't require serialisation, but if the application recycles, the session data is lost.
3.b. SqlServer, session objects are serialised and stored in a Sql Server database. Requires all session-stored items to be serialisable. Session objects persist even when an application recycles.
3.c. StateServer, session objects are stored in a seperate process, and persists data through application recycles.
3.d. Custom session provider, that's up to you....
ViewState, this is where data is persisted to the client-side and is posted back to the server to rebuild control states between page views.
I would avoid using static instances and the HttpRuntime cache for anything user related. Use these mechanisms for shared, common information, such as configuration, caching, etc. Session is likely the place you want to store things on a per-user basis. If you are looking for a per-page solution, its a lot simpler, because you simply make the variables part of the page structure itself, as properties or fields. You just have to manage the initialisation of these fields.
Hope that helps.