CallContext vs. ThreadStatic vs. HttpContext[待翻译]

http://forum.springframework.net/showthread.php?t=572

Hi all,
Since usage of [ThreadStatic], CallContext and HttpContext in Webapplications has already been discussed several times but imho to little, I would like to start an explicit thread on this topic. I think it's vital for avoiding unexpected problems.
I knew it is possible in ASP.Net for a Request to start on thread A and finish on thread B. This is called "thread-agility" by the NET-Team. Therefore I've always been convinced, that choosing CallContext would be save for storing e.g. a NHibernate-Session at the beginning of a Request for use during the rest of the Request ("OpenSessionInView").
To make a long story short: I was completely wrong - the only safe store is HttpContext.Items!
Here is a real good article on this:
http://piers7.blogspot.com/2005/11/t...xt-and_02.html
I went a little deeper to find the reasons why. Here's what I found out:
Any Request starts processing by the next available IO-Thread of the ASP-Workerprocess. All Events during an ASP.NET Request (BeginRequest, AuthenticateRequest, etc.) are executed asynchronously by default. But normally each event completes synchronously, thus the Request continues executing on the same thread.
If any of these events doesn't complete synchronously, the corresponding WaitCallback queues executing of the next eventto the NET ThreadPool. The rest of the Request executes on this ThreadPool-Thread!
I've never understood, what the docs were talking about IO and Worker-Threads. Now I do. In Pseudocode deep inside of HttpApplication you'll find something like this:

Code:

void ProcessCurrentEvent()

{

  ...

  EventHandler eh = GetCurrentEventHandler()

  IAsyncResult ar = eh.BeginExecute( this, WaitCallback, ... )

  if ( ar.CompletedSynchronously )

  {

    ContinueWithNextEvent()

  }

}



void WaitCallback( IAsyncResult ar )

{

	WaitForCompletion( ar )

	ThreadPool.QueueUserWorkItem( ContinueWithNextEvent );

}



void ContinueWithNextEvent()

{

  // Set HttpContext.Current

  CallContext.SetData("HtCt") = this.Context;

  AdvanceToNextEvent()

  ProcessCurrentEvent()

}

I hope I could work out the crucial points with this pseudocode. In the worst case, each event may execute on a different thread. The only thing that stays is HttpContext because it's set on the callcontext each time at the beginning of an event.
The big Problem: This affects nearly everything I've seen from Spring's code so far - and all other libaries I'm using, including most code I've written myself ...
I've attached a sample-web illustrating this (you must reference log4net for compiling). Just call /testasynccalls.aspx and hit F5 several times. You'll most likely see that the Thread-ID set during page-ctor is different from the Thread-ID during rendering the page. Even worse: Although the Thread-ID sometimes is the same, you'll see the value from CallContext has disappeared. That's because the previous thread has been returned to the ThreadPool and by fluke the same Thread is reobtained from the ThreadPool. But the ThreadPool clears a thread's CallContext before using it.
How does the sample work:
During Page-Construction 3 WebService calls are scheduled to be executed during the PreRequestHandlerExecute-Event. These Webservice calls are executed asynchronously to improve performance. Since the calls don't complete synchronously, the following ExecuteHandler-Event already executes on a ThreadPool-Thread.
By the way: This sample is the outcome of my experiments for simplifying performance-optimal calls to WebServices from ASPX-Pages inspired by this article:
http://msdn.microsoft.com/library/de...ce07222003.asp
I think, it's a real cool feature ;-)
br,
Erich

Attached Files

webservice_aspx_performance.zip (20.5 KB, 42 views)