Hi Bill,
You could spy on what order events are processing and objects are created using
Trace logging. Call Trace.Write() in your Module's Init function and event
handlers. Assign a random number ID property to the Module in the init
function and output that ID in the trace function in each of the event handlers
in your module, in Global.asax for BeginRequest, EndRequest, Application_Start,
Application_End, etc.. You'll need to adjust web.config to dump the trace log
to the browser. You can adjust the number of worker processes for your web app
in the IIS admin in case you've only got one running now.
You will typically have at least one HttpApplication servicing an ASP.NET
application, but there can be more than 1 (I use 1 instance per CPU and/or core
for development). Each HttpApplication is maintaining a thread pool that it
uses to generate an instance of the appropriate IHttpHandler (a page that
derives from System.Web.UI.Page being the most common) for each incoming
request & firing the HttpModule events before and possibly after the
IHttpHandler runs.
There are 2 collections/data stores that you can access during the course of
request processing. HttpModules should have access to both. One is the
Application collection and another is the Context collection (sometimes
Context, sometimes HttpContext.Current). The Application collection is shared
across all HttpApplication instances and is only emptied when the entire
application recycles or the web server is shutdown. I don't think you'd get
this IPC/shared memory behavior with a static property in your HttpModule. The
Context collection only lives as long as current request. You can read & write
to it in your HttpModule or in global.asax, and down at the page/control level.
When you write a value to the context collection, it can't be accessed from
another user's request thread and once the Response is sent back to the
browser, it's gone forever.
I'm 99% sure that access to the Application object is thread safe, but there is
a performance penalty--while the application instance is waiting for a lock on
the collection, the user's request is stalled. I don't think it can be used to
share data across multi-server web farms (you'd probably have to use a DB
server to store data for multiple servers to share), but I know that when you
have multiple HttpApplication objects running on the same machine, they can
share information through the collection. I'm not sure whether the compiler is
protecting you from race conditions on volatile-type read-write operations.
For example, if two instances of the HttpApplication try this at the same time,
is it possible for the read and write parts to be interleaved?
Application["RequestCount"] = ((int) Application["RequestCount"].ToString()) +
1;
vs.
lock(this) {
Application["RequestCount"] = ((int) Application["RequestCount"].ToString())
+ 1;
}
I'm not sure if you ended up picking up "Pro ASP.NET 3.5 in C# 2008" from
APress, but it has a pretty good section on 'Diving into the Architecture of
IIS' in Chapter 18.
Also, these might be useful:
http://msdn.microsoft.com/en-us/library/bb398986.aspx
http://msdn.microsoft.com/en-us/library/ms227673.aspx
http://msdn.microsoft.com/en-us/library/ms178473.aspx
http://msdn.microsoft.com/en-us/library/bb470252.aspx
Scott
-----Original Message-----
From: William G. Thompson, Jr. [mailto:[email protected]]
Sent: Friday, March 27, 2009 2:34 PM
To: [email protected]
Subject: [cas-dev] HttpModule threading model
Fellow Open Source DotNetHeads,
Anyone have a good resource on the HttpModule/HttpApplication threading model?
This thread (pardon the pun) [http://forums.asp.net/t/900381.aspx],
seems to indicated that only one request will be using an instance of
a HttpModule at a time. True?
Bill
--
You are currently subscribed to [email protected] as: [email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
