3

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?

RickAndMSFT
  • 20,912
  • 8
  • 60
  • 78
Tim Westover
  • 327
  • 1
  • 14
  • 1
    This is a lock on the session that prevents multi-threaded requests. If you don't need sessionstate, disable it in the page. If you do need sessionstate, sorry. Only one sessionstate-dependent request can execute at a time and the rest are queued. In MVC, there is an attribute you can use to mark methods or controllers as Session.ReadOnly (multiple requests can execute at once) that will allow this behavior. – ps2goat Nov 13 '13 at 22:14
  • Thanks for the info. I've set the target ajax page to EnableSessionState="False" in the Page directive. Still looks like it doesn't work. Do I have to turn off the session state on the origination page too? That I can't do. – Tim Westover Nov 14 '13 at 02:44
  • You shouldn't have to, but webforms may still lock up. I haven't gone back to test this theory, yet – ps2goat Nov 14 '13 at 04:52
  • In Azure, a cloud service (worker role) is the most robust mechanism. In WAWS, you can use the WebJobs SDK for long running asynch processes. See http://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/getting-started-with-windows-azure-webjobs – RickAndMSFT Jan 23 '14 at 01:03

1 Answers1

1

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: -

  1. use MSMQ; submit a message to a queue containing details of the operation to be performed, or
  2. 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 ?

sh1rts
  • 1,874
  • 1
  • 13
  • 14
  • That's correct, unless you're using WAWS. With WAWS, long running processes are supported. See http://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/getting-started-with-windows-azure-webjobs – RickAndMSFT Jan 23 '14 at 00:57