Does ASP.NET support reliable request processing even after a user navigates through javascript?

Question

Environment:

• Windows Server 2003 - IIS 6.x
• ASP.NET 3.5 (C #)
• IE 7,8,9
• FF (regardless of the last 10 versions)

User scenario:

The user enters search criteria for a large data set. After starting the query, they are moved to the results page, where they are waiting for the data to load and can then refine the data.

Technical scenario:

After the user submits the search criteria (via an ajax call), the user interface calls the background call. The internal service requests the transaction system and places the received data in the "cache" db - denormalized table, setting for further refinement of the data (ie Sorting, filtering). The user interface waits until the data is cached, and then, having received a notification about the completion of the process, it will go to the resulting page. The resulting page then calls a call to retrieve data from the denormalized table.

Problem:

The search is relatively slow (15-25 seconds) for large queries, as a result of which many systems have to query based on the entered criteria. This is relatively fast for other queries (<4 seconds).

Technical limitations:

• We cannot completely reverse engineer this search / result system. There are many complexities here between how an interface and an internal interface are interconnected. A page is required (due to restrictions that cannot be resolved on StackOverflow) in order to go after fulfilling the search criteria.

• We also cannot ask the organization to denormalize data before searching, because the data must be in real time, that is, if the user makes changes to other systems, the data must be displayed correctly if they are searched later.

The process I want to execute is:

• I want to cheat a little. I want to issue a cache request via the asynchronous HttpHandler in a restart model.

• After issuing the request, I want to transfer the page to the resulting page.

• On the transition page, I want to poll the Cache table to see if data has been inserted into it yet.

• The reason I want to make this transition right away is that the resulting page is expensive in itself (even without receiving data) - another 2 seconds of loading time before even calling a service that receives data from the cache.

Question:

Will the ASP.NET thread that is called through the async handler continue processing reliably even if I go from the page using javascript redirection?

Technical boundaries 2:

Yes, I know ... This search process does not seem effective. There is nothing I can do about it right now. I'm trying to do my best to make it work a little better, while we continue to study how we are going to redesign it.

If you answer: “Drop it and start again”, please do not answer. This is unacceptable.

Answer 1

Yes.

There is a Response.IsClientConnected property that is used to determine if a long process is still connected. The reason for this property is the processes that will continue to work, even if the client is disconnected and must be detected manually through the property and manually disconnected if a premature shutdown occurs. By default, the running process does not stop when the client disconnects.

Link to this property: http://msdn.microsoft.com/en-us/library/system.web.httpresponse.isclientconnected.aspx

Update

FYI is a very bad property to rely on these days with sockets. I strongly recommend that you take an approach that allows you to quickly complete a query that notes in some database or in a queue of some long-term task, perhaps uses RabbitMQ or something like that in turn uses socket.io or similar to updating a web page or application after completion.

Answer 2

How to do without an async operation in an ASP.NET thread? Let the ASP.NET code call the service for the data search queue, and then return to the browser with the token from the service, where it will be redirected to the results page, which expects the completed result? The results page will be polled using the token from the service.

This way, you don’t have to worry about how ASP.NET somehow finds out that the browser has moved to another page.

Answer 3

Another option is to use Threading ( System.Threading ).
When the user submits the search criteria, the server starts processing the page request, creates a new thread responsible for performing the search, and completes the response, returning to the browser and redirecting the results page, while the thread continues to run on the background server.
The results page will check on the server if the query has completed as the initial thread shares progress information. When it ends, the results are returned when the next ajax call is made on the results page.

You can also use WebSockets. In a sense, the web server itself could tell the browser when it will process the execution of the request, since it offers full-duplex communication channels.