Asp.net| Schema | Request when a request arrives, it is routed to the Isapiruntime.processrequest () method. This method invokes the Httpruntime.processrequest method, which does something important ( Use Reflector to view System.Web.HttpRuntime.ProcessRequestInternal method):
• Create a new HttpContext instance for the request
• Get a HttpApplication instance
• Call the HttpApplication.Init () method to set the pipe event
· The Init () method triggers the Httpapplication.resumeprocessing () method that starts ASP.net pipeline processing.
First, a new HttpContext object is created and used to pass the Isapiworkerrequest (ISAPI ECB wrapper). This context is always available throughout the lifecycle of the request and can always be accessed through static property Httpcontext.currect. As the name implies, the HttpContext object represents the context of the current active request because he contains all the typical objects you need to access in the request lifecycle. : Request,response,application,server,cache. HttpContext.Current gives you the ability to access all of these at any time of request processing.
The HttpContext object also contains a very useful collection of items, You can use it to save data for a particular request. The context object is created at the beginning of the request cycle, is disposed at the end of the request, and all data saved in the Items collection is available only in this particular request. A good example of use is the request log mechanism, when you pass through in Global.asax to hook up applic The Ation_beginrequest and Application_EndRequest methods record the start and end times of the request (as shown in Listing 3). HttpContext is very useful to you-if you need data in different parts of the request or page processing, you are free to use it.
Listing 3-Using the Httpcontext.items set allows you to save data in different pipe events
protected void Application_BeginRequest (Object sender, EventArgs e)
{
Request Logging
if (App.Configuration.LogWebRequests)
CONTEXT.ITEMS.ADD ("Weblog_starttime", DateTime.Now);
}
protected void Application_EndRequest (Object sender, EventArgs e)
{
Request Logging
if (App.Configuration.LogWebRequests)
{
Try
{
TimeSpan Span = DateTime.Now.Subtract ((DateTime) context.items["Weblog_starttime");
int milisecs = Span.totalmilliseconds;
Do your logging
WebRequestLog.Log (APP.CONFIGURATION.CONNECTIONSTRING,TRUE,MILLISECS);
}
}
}
Once the context is set, the ASP. NET requires the HttpApplication object to route incoming requests to the appropriate application/virtual directory. Each asp.net application must be set to a virtual directory (or Web root) and each "application" is handled separately.
HttpApplication is the host of similar ceremonies-it is where the action begins.
Master of the domain: HttpApplication
Each request is routed to a HttpApplication object. HttpApplicationFactory class creates a HttpApplication object pool for your ASP.net application based on the load of the application and distributes HttpApplication objects for each request 's Reference. The size of the object pool is limited by the maxWorkerThreads set in the processmodel key in the Machine.config file, which defaults to 20. This may be wrong, depending on the reflector decompile code, the pool size should be 100 , if the pool size is less than 100,httpapplicationfactory, 100 will be created, but considering that there are multiple threads creating HttpApplication at the same time, it is possible to have more than 100 in the actual case.
The object pool begins with a smaller number; it is usually the same number of requests that then grow to and occur simultaneously. The object pool is monitored so that it may increase to the maximum number of instances under heavy load, and a smaller number when the load is lowered.
HttpApplication is the external wrapper for your Web program, and it is mapped to classes defined in Global.asax. It is the first entry point into the httpruntime. If you look at the Global.asax (or the corresponding code class) You will find that this class inherits directly from the HttpApplication:
public class Global:System.Web.HttpApplication
The primary responsibility of HttpApplication is to act as an event controller for the HTTP pipeline, so its interface consists primarily of events. Event hooks are very extensive, including the following:
· BeginRequest
· AuthenticateRequest
· AuthorizeRequest
· Resolverequestcache
· Aquirerequeststate
· PreRequestHandlerExecute
·... Handler Execution ...
· PostRequestHandlerExecute
· ReleaseRequestState
· Updaterequestcache
· EndRequest
Each event is implemented as an empty event at the beginning of the Application_ prefix in the GLOBAL.ASSX file. For example, Application_BeginRequest (), Application_authorizerequest (). These processors are provided for ease of use because they are often used in programs so that you do not have to explicitly create these event handling delegates.
It is important to understand that each ASP.net virtual directory runs in its own application domain and that there are multiple instances of HttpApplication running in the application domain that are returned from ASP.net managed pools, which is why multiple requests can be processed simultaneously without interfering with each other.
View list 4来 Gets the relationship between the application domain, the thread, and the HttpApplication.
Listing 4-Displays the relationship between the application domain, the thread, and the HttpApplication instance.
private void Page_Load (object sender, System.EventArgs e)
{
Put user code to initialize the page here
This. ApplicationID = ((Howaspnetworks.global) HttpContext.Current.ApplicationInstance). ApplicationID;
This. ThreadId = Appdomain.getcurrentthreadid ();
This. Domainid = AppDomain.CurrentDomain.FriendlyName;
This. Threadinfo = "ThreadPool Thread:" + System.Threading.Thread.CurrentThread.IsThreadPoolThread.ToString () + <br> Thread Apartment: "+
System.Threading.Thread.CurrentThread.ApartmentState.ToString ();
Simulate a slow request so we can-multiple
Requests side by side.
System.Threading.Thread.Sleep (3000);
}
This is part of the demo provided with sample, and the results of the run are shown in Figure 5. Run two browsers and open this demo page to see different IDs.
Figure 5-You can simply view the application domain by running multiple browsers at the same time, and how the application pool instance and the request thread interact. When multiple requests are initiated at the same time, you can see that the thread ID and application ID have changed, but the application domain is the same.
You may notice that on most requests, the application domain ID remains the same when the thread and HttpApplication IDs change, although they may also be repeated (referring to threads and HttpApplication IDs). The HttpApplication is removed from a collection and can be reused in subsequent requests, so its ID is sometimes duplicated. Note that application instances are not bound to specific threads-they are, exactly, the active threads that are assigned to the current request.
