Are there any ways in ASP.net to fetch data from the server without extending the session timeout? This needs to be done every few minutes without user interaction until the page is closed.
Additional context, as requested:
The pages in my webapp needs to poll the server every few minutes to check for a particular condition (emergency maintenance scheduled for 30 minutes time, in this instance). When the condition is true, the page will display a message to the user. When the condition is false, nothing needs to happen.
As I understand it, postbacks to the server reset the time until the session expires. We do not want the session to be extended/refreshed/reset/whatever the word is every time the page polls the server. I need a way to poll the server automatically without resetting the session timeout.
Thanks.
If you're asking in the context of a lengthy HTTP request, so that you're looking to prevent an HTTP timeout, look at web.config's <httpRuntime executionTimeout="99999"></httpRuntime> where executionTimeout is in seconds I think, http://msdn.microsoft.com/en-us/library/e1f13641(v=vs.71).aspx.
If it is truly just a session timeout issue, is it possible to asynchronously ping the server under the same user session, while the lengthy process is running?
Edit:
Based on your edit, if you partition your "web site maintenance" web service into a service outside of the session state scope of the normal part of the site, then you can call it as often as you'd like. If you're using an ASMX web service in your current website at this time, for example, simply partition it into a separate application, perhaps as a directory off of your application, so that it falls under the same domain. I imagine that would work fine.
I'm not sure what web service type you're invoking at this time (ASMX, WCF, etc.), or even if the web service that you're invoking at this time is in the same application as your ASPX application pages.
First, if a query is running beyond the session time limit then there is a serious problem with the query. I would rather fix the query first.
However if you still want to do it using the session, try this:
You can have a Dummy.aspx in your app and then have a image element refresh its URL every 15 minutes like:
<img id="dummyImage" src="/Dummy.aspx" width=0 height=0/>
<script type="text/javascript">
var dummyImage = document.getElementById("dummyImage");
setInterval(function(){
dummyImage.src = "Dummy.aspx?_tmp=" + (Math.random() * 100000);
}, 900000);
</script>
This way you will not impact the session timeout at a global level.
Use a javascript timer which fires an AJAX call. So in your PageLoad event echo out a javascript setInterval(functiontocall(), timetowait); function. The method you call will be the AJAX hit to a web service which does your query.
This will keep calling itself until the user closes the page.
Sessions do not get refreshed from AJAX hits.
Related
First of all, let me ask this:
Let's say that a web application has its timeout set to 10 minutes. For some reason, the user is idle. If he/she returns and press any key or moves the mouse, it resets the timeout? Or it is based on the last time it went to the server?
And now the second question: is there a way to find the time until the user gets logged off due to innactivity?
From MSDN:
The Timeout property specifies the time-out period assigned to the
Session object for the application, in minutes. If the user does not
refresh or request a page within the time-out period, the session
ends.
So in answer to your question, the timeout is reset if the user sends a request to the server by either navigating to another page or refreshing the current page (or possibly by using some form of AJAX keep-alive method (See this question)).
This article on Code Project provides a pretty good overview of Sessions within ASP.net
For your second question, this gets a little complex as the session timeouts are managed by IIS so your page has no idea how much longer the session will be valid for. I have seen examples where another timer is placed with in the page itself and when this reaches a certain low value the user is warned that their session is about to expire. The page could then refresh (resetting the session timeout value in IIS) and the user wouldn't be logged out / lose their session.
However, this will require the session timeout value that is configured is kept in sync with the value configured in the JavaScript function.
I have an MVC3 application that takes 30+ seconds for global.asax Application_Start() to execute. When a user hits the site for the first time after the App Pool was reset, the browser just sits there with a "waiting for website..." message.
Is there a way to show a "Loading data..." message/page to let the user know that everything is OK and to be patient?
No, there's no way to show any messages from Application_Start. IIS 7.5 has a cool AutoStart feature which allows you to preload your application in memory and thus avoid the long waiting. Another possibility is to have some external service that queries your site at regular intervals so that it doesn't get unloaded by IIS.
If you cannot use this feature, then you will have to reduce/optimize the amount of work you do in your Application_Start so that it doesn't take 30 seconds.
Not within the same .net application - you can't show anything from within Application_Start. You could create another small app as a landing page which polls for a response from your main app and then redirects once it gets one.
But a better solution would be to move some work out of Application_Start - can't you let the user arrive at your first page and then call an initialization method once they have landed?
You can't do that in that particularly way, as there is no response from the server, and for such, you can't do anything.
But how about to implement a heartbeat that will query any URL of your application avoiding it not to enter in stand mode?
an idea: Set an external service to query your application every 5 minutes:
RestSharp requests on momentapp's restful api
I have a hosted Silverlight 4 application. My task is to notify a Silverlight user when his ASP.NET session is about to expire with a simple dialog box, saying something like "Your session is about to expire, would you like to reset the session?" with two buttons [Yes], and [No]. When the user clicks [Yes] I would like to update the ASP.NET session, otherwise I would just let it expire. What is the best methodology to use here?
I've taken a look at different forums, and most people just simply poll the server every-so-often from the page hosting the Silverlight application. This wouldn't do for me. I thought of creating a singleton DispatcherTimer that would start on Silverlight application startup, would fetch Session.Timeout value from the server using WCF and would run for (Session.Timeout - some delta) minutes. When the timer expires it would pop the notification window. Moreover, since this notification window should only pop after a period of inactivity, I'd like to reset this timer every time a WCF call is performed (which essentially defines activity). Is this sound? Are there any better methods? What are your thoughts?
P.S. I'm also planning on doing something similar for Forms timeout.
You may or may not be opposed to this, but I've found it useful in RIAs to have a timer running that makes a keep-alive request to the ASP.NET server in order to prevent the session from expiring while the application is active. At the same time, in case something happened on the server that caused the session to expire, you could detect that condition in the keepalive handling and tell the client that the expiration has taken place.
I am not able to make more than one request at a time in asp.net while the session is active. Why does this limitation exist? Is there a way to work around it?
This issue can be demonstrated with a WebForms app with just 3 simple aspx pages (although the limitation still applies in asp.net mvc).
Create an asp.net 3.5 web application.
There should be just three pages:
NoWait.aspx, Wait.aspx, and SessionStart.aspx
NoWait.aspx has this single nugget added between the default div tags: <%=DateTime.Now.Ticks %>. The code-behind for this page is the default (empty).
Wait.aspx looks just like NoWait.aspx, but it has one line added to Page_Load in the code-behind: Thread.Sleep(3000); //wait 3 seconds
SessionStart.aspx also looks just like NoWait.aspx, but it has this single line in its code-behind: Session["Whatever"] = "Anything";
Open a browser and go to NoWait.aspx. It properly shows a number in the response, such as: "633937963004391610". Keep refreshing and it keeps changing the number. Great so far! Create a new tab in the same browser and go to Wait.aspx. It sits for 3 seconds, then writes the number to the response. Great so far! No, try this: Go to Wait.aspx and while it's spinning, quickly tab over to NoWait.aspx and refresh. Even while Wait.aspx is sleeping, NoWait.aspx WILL provide a response. Great so far. You can continue to refresh NoWait.aspx while Wait.aspx is spinning, and the server happily sends a response each time. This is the behavior I expect.
Now is where it gets weird.
In a 3rd tab, in the same browser, visit SessionStart.aspx. Next, tab over to Wait.aspx and refresh. While it's spinning, tab over to NoWait.aspx and refresh. NoWait.aspx will NOT send a response until Wait.aspx is done running!
This proves that while a session is active, you can't make concurrent requests with the same user. Requests are all queued up and served synchronously. I do not expect or understand this behavior. I have tested this on Visual Studio 2008's built in web server, and also IIS 7 and IIS 7.5.
So I have a few questions:
1) Am I correct that there is indeed a limitation here, or is my test above invalid because I am doing something wrong?
2) Is there a way to work around this limitation? In my web app, certain things take a long time to execute, and I would like users to be able to do things in other tabs while they wait of a big request to complete. Can I somehow configure the session to allow "dirty reads"? This could prevent it from being locked during the request?
3) Why does this limitation exist? I would like to gain a good understanding of why this limitation is necessary. I think I'd be a better developer if I knew!
Here is a link talking about session state and locking. It does perform and exclusive lock.
The easiest way around this is to make the long running tasks asynchronous. You can make the long running tasks run on a separate thread, or use and asynchronous delegate and return a response to the browser immediately. The client side page can send requests to the server to check and see if it is done (through ajax most likely), and when the server tells the client it's finished, notify the user. That way although the server requests have to be handled one at a time by the server, it doesn't look like that to the user.
This does have it's own set of problems, and you'll have to make sure that account for the HTTP context closing as that will dispose certain functionality in the asp.net session. One example you'll probably have to account for is probably releasing a lock on the session, if that is actually occurring.
This isn't too surprising that this could be a limitation. Each browser would have it's own session, before the advent of ajax, post back requests were synchronous. Making the same session handle concurrent could get really ugly, and I can see how that wouldn't be a priority for the IIS and ASP.NET teams to add in.
For reasons Kevin described, users can't access two pages that might write to their session state at the same time - the framework itself can't exert fine-grained control over the locking of the session store, so it has to lock it for entire requests.
To work around this, pages that only read session data can declare that they do so. ASP.NET won't obtain a session state write lock for them:
// Or false if it doesn't need access to session state at all
EnableSessionState="ReadOnly"
I have an Ajax request to a web service that typically takes 30-60 seconds to complete. In some cases it could take as long as a few minutes. During this time the user can continue working on other tasks, which means they will probably be on a different page when the task finishes.
Is there a way to tell that the original request has been completed? The only thing that comes to mind is to:
wrap the web service with a web service of my own
use my web service to set a flag somewhere
check for that flag in subsequent page requests
Any better ways to do it? I am using jQuery and ASP.Net, if it matters.
You could add another method to your web service that allows you to check the status of a previous request. Then you can use ajax to poll the web service every 30 seconds or so. You can store the request id or whatever in Session so your ajax call knows what request ID to poll no matter what page you're on.
I would say you'd have to poll once in a while to see if request has ended and show some notifications, like this site does with badges for example.
At first make your request return immediately with something like "Started processing...". Then use a different request to poll for the result. It is not good neither for the server nor the client's browser to have long open HTTP sessions. Moreover the user should be informed and educated that he is starting a request that could take some time to complete.
To display the result you could have a"notification area" in all of your web pages. Alternatively you could have a dedicated page for this and instruct the user to navigate there. As others have suggested you could use polling to get the result.
You could use frames on your site, and perform all your long AJAX requests in an invisible frame. Frames add a certain level of pain to development, but might be the answer to your problems.
The only other way I could think of doing it is to actually load the other pages via an AJAX request, such that there are no real page reloads - this would mean that the AJAX requests aren't interrupted, but may cause issues with breaking browser functionality (back/forward, bookmarking, etc).
Since web development is stateless (you can't set a trigger/event on a server to update the client), the viable strategy is to setup up a status function that you can intermittently call using a javascript timer to check whether your code has finished executing. When it finishes, you can update your view.