I have a problem with an asp.net site (4.0 framework) I would like to understand how to properly discard of values in HttpRuntime.Cache between page requests. I am storing values for pagination , control state etc on a search page, and it works fine .. except the values for controls exist (eg. combo box selection) if i open a different browser and open the page.
You should not be using Cache in this way. Not only is it cross-browser-window... it applies to the whole application.
You should use querystring/form values for saving which page is being viewed, instead.
If you want a storage per session, the HttpContext.Current.Session is a good place to put it. As Andrew Barber points out, the Cache is application-wide (shared by all users and sessions)
Related
I have a Layout page which sets up the list of Projects in the application using Telerik's ComboBox as shown. The combobox allows user to select a project he/she wants to work on.
Once a selection is made, I want all subsequent actions in the application should correspond to the selected Project. I can preserve the Project information in a Session but then if user chooses to open this in a new tab and in 2nd tab users switches to a different Project and comes back to the first tab and refreshes the page then the session information (Project) would have changed which will create issues in my application.
So, what is the best way for me to persist Project information of the Layout.cshtml controls so that I can use it in my application such that every page that is rendered uses the currently/correctly selected values.
Tempdata / QueryStrings came to my mind but i don't know whether they will be reasonable solution to my problem. If yes, then how should I use them generically (specially querystrings) without complicating my solution?
localStroage and sessionStorage also seems like relevant solutions but then how do I use them in scenario where user opens a new tab from existing page? How will the Project # will persist on the newly opened page/window/tab?
something like this is achievable, if you make sure the url changes when a selection is made.
So let's say you select project C-1379 in your dropdown box, at that point your url could become http://localhost:58692/pid=C-1379.
from now onwards, your page can load the desired data, retrieving its required information from the query string. Do not use session or localstorage or anything like that as it won't work.
This way, you can still load your list of projects in your layout page, and you can select one based on the query string value and then load some default values via api calls to the back end.
If all your work from now on is done based on api calls, for example, you have some properties that you change and then you issue a POST to update said details then this is very easily done as well.
telerik controls usually have some events associated with them. the one you are using should have an onChange or something like that. This where where you would update the query string with the value of the project selected and then you can proceed to do what you need
I can preserve the Project information in a Session but then if user
chooses to open this in a new tab and in 2nd tab users switches to a
different Project and comes back to the first tab and refreshes the
page then the session information (Project) would have changed which
will create issues in my application.
I would have thought this is the desired behavior... take stackoverflow.com as an example, if I change my username in one browser-tab, I would expect my username to be updated in other browser-tabs as well... and that's what happens if I refresh my other tab.
There is no built in solution for maintaining user info in different browser tabs separately... the only way to achieve this, is by sending project name back and forth in the URL... but then you would loose this info if user changes the URL... In my opinion, this is an ad hoc solution and does not worth the effort of development, because it's a very uncommon scenario.
Getting to your options:
Storing user info is a very typical use case for session variable.
TempData is stored in Session by default. Though you can write
your own custom TempDataProvider and store it somewhere else (e.g.
database, cookie, etc). See Brok Allen's Cookie TempDataProvider
as an example. One advantage of using Cookie is that you send your
session variable back and forth with the request so you don't need to
worry about Sticky Sessions.
You can of course use a permanent storage, such as DB/Disk.
If the project name is not a sensitive info then I don't see any issue in passing it in Query String.
I'm working on a business application using ASP.NET Ajax , NHibernate and Spring.Net, I've got an annoying problem. The problem is that when I leave page for about 5 minutes and then return back and try to make any action that posts back, it displays wrongly (if there are controls hidden by style it became visible). In addition, the page didn't post back to the server.
Also the problem happens when opening two different tabs, different pages (Each page uses session but different keys )
Thanks in advance
As you describe the problem, its sounds that connect the content of the page with the user cookie and session, and when the session expired the application did not take care to recreate it.
So the post back fail because the session data have been lost when the page ask for them / need them to work and display correct the results.
This is the issue that I diagnose, how you fix that is up to you :)
Possible solutions
Change the logic of the page creation.
While the user is on page do not let the session ends (not good practice)
Store the user data of the page, on a database - connected with the user, and delete it after some days if not have been updated.
We're developing a video site that will be on sharepoint,
we want to limit the users to be able to watch 1 video at a time.
The limitations I have for this:
-Enable session state is not active in the farm
The things I do have control on:
-Master page
-The code itself(the video webpart etc)
The problem with Cookies for instance, is when to delete them,
I override "unload" and "dispose" events of the webparts and the page.Request wasn't available in that context
If there are solutions with Session - do suggest, but I prefer solution without the need to activate it
Thanks in advance.
found the solution for anyone who's looking:
first I put a check if there's an existing cookie on the relevant webparts, if not I create those webparts as usual and create the cookie
Second I registered the event "onunload" of the body element in the masterpage,
there I put javascript that called webservice which is responsible of clearing the created cookie- only if it was created from the same location who called the "onunload" event(I kept the url as value in the cookie)
If session is usable- the solution is the same just keeping the data in the session
Thanks for your comments
The problem that I am having is as follows:
I currently have a custom class that generates buttons and places them on a placeholder on a master page.
The events for these buttons put specific values into session that differs values for a database query. In essence, the buttons serve as filters for charts.
After creating all the buttons, I realized that session values will stay constant from page to page, so everytime a user enters a different page while another is open, the filters selected on the open page will remain constant for the new page that is opened.
At first, I wanted to use viewstate rather than session, but then realized that a master page and a content page do not share the same viewstate.
At the current time, I am thinking of using a prefix for the sesson key that will identify what page the filters actually exist for. However, I am not wanting to overload session with numerous values if the user wishes to have many pages open at the same time.
Any solutions that would entail a way to share viewstate (or some other way to store values) between app_code, the master, and the content page?
Use HttpContext.Current.Items, it is a key-value pair collection with a lifetime of a single Http Request.
Have you considered Context.Items?
How many filters are we talking here? Store the filter values in the URL. Have you seen some of the URLs that google or an ecommerce site uses? They are quite long. Here is how I do it:
I store the filter values in the query like, www.chart.com?filter1=val1&filter2=val2 etc.
I user JQuery's query plugin to manipulate the query on the client side, and then request the chart from the server again, using the new query.
This way, I'm not junking up session, cookies, or anything like that, and if the user wants to store a bookmark to a particular chart or email it to a friend, they can and the filters are preserved.
I'm starting to think the answer shown in the following question will work:
ViewState object lost in Master Page Load
Exposing the desired variables via a property.
If the data isn't too long, cookies are a typical solution.
Another option is to use Silverlight isolated storage. The Silverlight control itself could be invisible (no UI).
It is my understanding that page level caching does not take into account that, for authenticated sites, different users may request the exact same page (URL) while the rendered page itself is different (because it contains stuff that is user specific).
Unless you activate cookieless authentication (then the sessionID becomes part of the URL) all users will see the same cached page (regardless of who they are).
Is this correct?
Yes, you are 100% correct on this one.
Typically I'll move to user controls, to be able to cache the user controls of the items that do not change from user to user.
You can then use Session, or another cache store if you must cache user specific data.
Depending on how much dynamic contnent you have on a page you could use the Substitution control to render dynamic content on a cached page.
This control is bound to a static method (remember that the page lifecycle hasn't run as this is cached version of the page and none of the objects created in Page_Load etc wiil be available) that returns dynamic content and can be positioned wherever you want on the page.
<asp:Substitution ID="mySubstitution" runat="server" MethodName="GetLoggeninUserName" />
The other option is "Donut Caching" as Scott Guthrie calls it:
Implement "Donut Caching" with the ASP.NET 2.0 Output Cache Substitution Feature
This allows you to have page level caching, while implementing certain elements in non-cached "holes".
Yes you're correct and the Substitution control noted by Andy (and Zhaph) is your best answer if you're using ASP.NET 2.0 or above. Creating separate user controls for the non-user-specific content is a less ideal approach that should only be used if you're stuck working with ASP.NET v1.x (so you should mark Andy's as the answer, I would think).