I was hoping if anyone can answer a fundamental question that I have regarding refreshing of a web page.
I have a dotnet webform where a user fills in some details and clicks submit. The code behind of the webpage has about 20 functions to perform.
Now assuming, when the user clicks the submit button the web page is executing the 5th function and meanwhile the user refreshes his browser;
What will happen to the already processing page?
Will the page be terminated immediately?
or will it be allowed to run till it executes the 20th function?
or will the page running be destroyed and a new page created and sent to client?
Thanks for your answers.
Once a request is made to the server from the browser the page is processed. Even if the user cancels or stops the request, the server continues to process the request. If the user reloads/refreshes the page, it's another request that will be executed in parallel with the first request.
Even in the case of PHP, the server isn't actively checking if the user has aborted the connection. The server only knows it's been aborted when it attempts to return the results of the request.
The internet is a disconnected environment. The server doesn't know anything about the browser. The only thing the server knows is a request has been made and it must fill the request.
When a page is refreshed on the browser, the browser calls on the server for a fresh copy of the page and its components (CSS, JS, and so on... if not cached).
If the page was a POST call, the browser will POST the data again.
Page has completed loaded:
When loaded completely, the execution on the server side should be completed (unless you execute additional processes, or run background code which will not send anymore data to the client).
Page is loading halfway through:
The connection for the current page will be immediately disconnected - if the page is still loading. It depends on the server whether for the page to continue running or terminate. For example in PHP we can ignore_user_abort() to keep the script running even if the page was terminated halfway through loading.
If your server is ASP, and you click on an ASP button, the action (method) of the button will be done completely on server side even if the user refreshes halfway through. That is how ASP.NET framework is done.
Simply, the page the user is seeing is lost unless in session, they can not pick it up again. But the server does not know that the user has disconnected so the application will continue to run, unless there is a session / timeout on the application, even then it would be odd if the session did not complete.
Hope this helps.
RE
The code execution will continue to the end.
I believe a web page (on the client side of course) is executed in a single thread. If your "onsubmit" calls a trail of functions, that's up to you but at some point you will (maybe) want to submit() the form.
In other words (in your specific case), all the function trail will continue until the form is sent.
On the other hand, if you press the "reload" button, the execution is terminated.
all the funcs will be executed, even you have refresh, you can do a test. but in .net it provide a function to check if client is still connected with server (for your first submit, mean the server can check if client is waiting for the response at anytime after you submit)
Related
I am using asp.net and Ajax functionalities to make requests to server via web services for a search functionality. On click of search button, I am making the screen inactive by displaying a loading image over it. The issue is some searches takes longer time, and the user is forced to wait till the results are fetched. Is there any way the search can be cancelled manually, like a button click while the search is being performed by the server.
Any help or alternates will be appreciated.
One thing you can try is to set timeout on your ajax call, take a look here:asp-net-page-webmethod-ajax-call-request-timed-out
Another thing is to use javascript setTimeOut to display the user a message after a few seconds saying "its taking too long. wait for results or Abort?" where the "Abort" is a link that refreshes the page.
In our web application, a user can make a change that requires a lot of database tables to update. The load time for all that can be up to 30 seconds. I don't want the user to wait for that to complete before navigating to another page.
I've put the long-running code on its own page (say, "updateinfo.aspx") and tried a few solutions, including jQuery AJAX calls to "updateinfo.aspx" or loading an image file that calls "updateinfo.aspx". In all cases, I cannot navigate from the original HTML page that kicked off the AJAX call to another HTML page while "updateinfo.aspx" is executing. Chrome says that the request to "updateinfo.aspx" is pending. When I click on a link to navigate away from original HTML page, we're "Waiting for example.org..." until the AJAX page is finished, then the request to navigate to the next HTML page follows through and the new page loads.
So, this defeats the purpose of putting the long-running code into an AJAX page. The user's page renders quickly, but they cannot continue about their day by navigating to another page until the AJAX page is finished. I don't care about the output of the AJAX page.
Any thoughts?
You shouldn't really execute a long-running process in a web page context; the HTTP Request/Response model is not favourable to that concept when the client application is a web browser. This is a scenario I have had to address a number of times; you could: -
use MSMQ; submit a message to a queue containing details of the operation to be performed, or
write the details of the operation to be performed to a "Jobs" table
You can then create a Windows Service to read messages from the queue/pull un-processed items one at a time from the table, and perform the long-running operation.
In the most recent project I had to do this, from memory, I created a usercontrol that sat in the header (i.e. in the masterpage) which polled the database table via jQuery Ajax once every 15 seconds to detect when the job was completed, and show a popup to the user indicating the job was finished.
I can try and dig out some examples somewhere but those are the main moving parts, does that help at all ?
I am developing a web application in classic asp, promptly the problem I'm having is related to a progress bar. I am doing some operations with the database that are too heavy, so in the middle of each iteration in the calculation, I'm doing a flush reporting the progress.
This page it's being called by an iframe and depending on the content we are updating the progress bar. The problem is that if I delete this iframe (and concecuentemente cancel the request), I can not navigate through the site until the end of the expensive operation.
Given this situation, I have two questions:
As from the server (asp page) how can I can detect when the request was cancelled?
What can I do to enable multi threading sessions?
You can detect if the user is still connected with Response.IsClientConnected. So you can add this to your long running code, eg:
If Not Response.IsClientConnected Then
'Stop processing
End If
Not sure about this. Is it only the one user who started the request that is effected or do all users have to wait? There may be a setting in IIS (you could try disabling HTTP keep alive, but it's just a guess).
I was wondering if there is any way to always run some server side code when a user leaves a page in ASP.NET. The page Unload event is no good because that doesn't get called if someone clicks on a link. Ideally I'd also like the code to run even if the user closes the browser.
I suspect what I'm asking isn't possible, but it doesn't hurt to ask
Problem is, HTTP is a stateless protocol, so when the page has finished being served, you wont know if the user is still on the page or not.
The only way to acheive this would be a hidden piece of Javascript that constantly pings the server with it's session ID, or another similar mechanism. When the ping becomes unresponsive you can reasonably assume the page is not being viewed by the user anymore.
Here is a diagram that explains traditional HTTP message flow.
im not really sure if you can do that but i have a workaround in mind.
There is an event in the DOM called onbeforeunload. it get calls everytime a user leaves a page. you can try sending an ajax request to the server from this function.
The closest thing you can come without creating too messy a solution is to enable ASP sessions. This will create a session on the server for each visitor, who will be identified by a cookie.
After a certain amount of inactivity from the visitor, the session will be closed, and a SessionEnd event will be raised. This you can hook up to in the Global.asax file.
I will not recommend this however, because HTTP is pr. definition a session-less protocol, and using server based sessions violates this fact, and are often problematic. Many solutions that use server based sessions run into problems when the user uses the browser-back button, and resubmits a form. Because the content of the submitted form no longer corresponds the data that exists in the server session.
Also, enabling server based sessions seriously hurts the scalability of the application.
Not that I know of. You'll need to use javascript for that, and call a web service on the server side.
I'm having a bit of trouble cancelling an asynch postback. I have an update panel with an update progress which contains a cancel button so that the user can cancel the postback. When the user clicks a button to generate a report the update progress is shown. The report can take a bit of time as it has to loop through a thousand or so times creating an excel spreadsheet. If the user decides to cancel running the report for any reason then they can click the cancel button which I then call abortPostBack() in javascript which stops the update progress and the page is shown again. However, the user can't do anything else like navigate to another page as the server is still processing the loop. How would I stop the loop on the server processing when the user has clicked the cancel button? Any help appreciated!
Are you saying that a simple HTTP link is not accessible on the client side until the async postback is complete? If so, that sounds like a conundrum, since you either have to optimize your server side process, or set a smaller server-side request timeout. Either that or redesign your user-interaction to make the server side Excel generation process an asynchronous one, rather than synchronous, so that the user doesn't have to wait until the Excel generation is complete. You could fancy this up on the client side to then set a JavaScript timer to periodically query the server to see if the file was ready, and if so, indicate that to the user with and give them a download file link option, or something.
Otherwise, if you could invoke another AJAX request while waiting on that to return (which you may not to from the sound of it), you could simply perform a new HTTP request that "cancels" the long running process. But that seems like it would not work since the server is still handling the long running HTTP request. So I'd opt to investigate the options in my first paragraph.
If cancelling did allow an async HTTP request to be performed on the client side, then you could set a session state value to indicate that cancel was requested. Personally I wouldn't approach it this way. But if you did, then your long-running server-side process could periodically look for the existence of a session value. Say:
if (Session["cancel-me"] != null)
{
Session["cancel-me"] = null;
abortThisLongProcess();
}
Yep, even if you navigate away from the page using the browser back button, as soon as you click anything else that needs to post back to the server the page hangs until the long process has completed. Looks like there's no way of canceling so I will have to look at redesigning the Excel generation.
I haven't found a way to cancel the request that's running, but there's no real reason that you can't start a new one.
By default ASP.Net tries (it can't always) to apply an exclusive lock on the session object - as soon as one page reads it every other page request that passes the same session ID (by cookie or on the URL) has to wait for the first page to release the session.
It doesn't matter that the client has cancelled the request - the server will continue to lock the session until the original page finishes executing.
I think the solution is to do away with the ASP session entirely. Then when the user requests another page it begins immediately, even though the server is still processing the old request on another thread.