Thread processing is different from IIS5 and IIS6, and I will discuss this issue shortly. For each request, a new instance will be created, in order to avoid too frequent allocation applications and modules, each application domain maintains the pool of the application and module. The maximum value of each application pool is consistent with the size of the thread pool. Therefore, it is default that the upper limit is 25 working processes can be concurrently processed, each with its own application and module collection. Figure 1 shows a snapshot of the ASP.NET work process. In this scenario, there are two activated applications in the working process, each application independent of your own application domain. Each application currently handles two requests, and each of them uses two threads from the CLR pool to respond to these requests.
Figure 1 Threads and pools
Several features of this structure may affect you build ASP.NET applications. First, applications and modules have been created multiple times that you can never rely on fields or other status, thinking that they cannot be shared across multiple requests, as you can think of. Alternatively, a status library can be used, for example, using the program range of Cache, SESSION state, application status, or set of each request (from httpcntext). In addition, you can also use static data in the case of proper synchronization.
By default, most of the devices that respond to requests are not using pools. You can use the pool handler, even the control pool every ISRESUSUSABLE OF IHTTPHANDLER, but only the handler that is implicitly doing the pool can be used as a custom handler (which does not have a specified processing factory written). PageHandlerFactory does not implement the pool, SimpleHandlerFactory is also the case, its instance is the processor with .ashx-defined. Typically, each request assigns a new proper handler object, after the request, the handler object will be completely discarded.
