Chapter 9. Asynchrony

9. Asynchrony

AT FIRST GLANCE, it almost seems unnecessary to discuss asynchrony in building Web applications with ASP.NET. One of the key advantages of building applications that execute in the context of a Web server is that the application is intrinsically asynchronous, without any extra effort on your part. For each page you write, you will undoubtedly have multiple concurrent users accessing that page once it is deployed. ASP.NET is built to handle as many concurrent requests as possible for any given application, and it manages the details of allocating and pooling threads for servicing requests. With each request, ASP.NET creates a fresh instance of the target page class, so unless you are dealing with globally or statically scoped data, you don't need to worry about the fact that client requests are fulfilled concurrently for your application.

While it is true that each page may be running on a separate thread, there are still occasions where introducing additional asynchrony into a request makes sense. The most obvious case is when a page is performing multiple time-consuming I/O-bound operations that could be made to run in parallel. By splitting tasks across multiple asynchronous I/O operations, the total response time of the page can be reduced. You can also introduce asynchrony into a request to relax contention for threads in the thread pool by launching one or more asynchronous requests and then returning the original request thread back to the pool, thereby completing the request only when all of the outstanding tasks have completed.

ASP.NET 2.0 provides support for introducing both of these types of asynchrony into your applications when needed. This chapter introduces the details of the asynchronous page model and three techniques for handling requests asynchronously: implicitly using the AsyncOperationManager, explicitly using asynchronous page tasks, and at a lower level using the AddOnPreRenderCompleteAsync method.