Just thought I'd throw this out there, because our company has a support ticket open with Microsoft about this very issue.

http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html

As far as we can tell, according to MS Support, ThreadStatic will not work, and HttpContext and CallContext are both highly suspect. We opened the ticket because no amount of Googling would give us enough details on ASP.NET thread pool behavior under high load. The ticket is not closed yet, and we still don't have a final answer.

Hope that helps. :)

Thanks for the info and for taking the time to write all that up. I guess things aren't as simple as I hoped they were.

This is almost as much fun as the PermGen OutOfMemoryError on webapp redeploy in the Java/Tomcat world.

fwiw, I've abused our MS relationship at work too and asked one of the MS guys on our team to do a little research on thread handling in ASP.NET to get a better answer than my speculation.

I forgot to mention that we're using .NET 1.1, and things may or may not be quite different in 2.0.

Everything from the research I requested of Microsoft regarding 2.0 jives exactly with your article and, with regards to TLS at least, will become more volatile in the future with things like Atlas.

I'll get more info and some state diagrams posted later.

Oh, and great article!

Hi Simon.

I have two questions about your solution:

1) Why have you used CLSCompliant(false)? Sorry, I didn't understand :(

2) How do you do when you have the following:



If these objects need to be saved using the same transaction, how do you perform this operation? As I saw, your Save() method calls transaction.Commit(), so I think you can't do it using that (Db.Save...) approach, right?

Thanks man!

After 4 weeks of waiting for an answer, Microsoft said that native code in the CLR ensures that HttpContext works across thread context switches in the ASP.NET thread pool, and is the correct usage, not TLS. Not a great answer, but it's something we can hold them to.

I have a multithreaded desktop application (C#/.Net2.0) where I have component that listens for and sends udp group broadcast messages to indicate a user has begun/finished working on a pending task. I am using udp to keep things simple and can't use the full blown messaging framework. The app uses this to force an update of the UI and provides some visual candy and allows others to see that item is in progress. In my form I have a event handler method that receives the message and then calls the form's Invoke method (Control.Invoke) to perform the update.

Where I am running into a problem though is with CallContext not being set up when an update is received, even though I am invoking the update action on the forms thread (or trying to :) ). While debugging, it looks like the update is being done in the correct thread, but for some reason the original connection in the CallContext isn't there. The app creates another connection and this leads to the object associated with two connections error.

Any ideas on what I could be doing wrong? Am I incorrect in my assumption that calling the Invoke on the form calls the passed delegate on the forms ui thread?

Any help or suggestions would be greatly appreciated.