Question

I am calling from one piece of my code through several layers of 3rd party code, and the call surfaces back into my code at some point by calling some code I’ve written.

In other words, the code call chain looks like this:

My code #1 --> 3rd party code --> My code #2

Unfortunately, nothing I pass to the 3rd party code is given to that second piece of code so I have nothing to tie the first piece and the second piece together, except for the fact that the code runs on the same thread.

So I was wondering if simply using [ThreadStatic] on a static field on a class would be a viable solution to this?

Since the code also runs in a web application, I cannot just use a static field for this, since the value I need access to (an object) is different for each user/session.

ie. I would do something like this:

internal static class DataHolder
{
    [ThreadStatic]
    internal static ClassName FieldName;
}

Are there other solutions to this?

Answer 1

In contrast to the other answers suggesting that this is ok, you should be very careful about using ThreadStatic or ThreadLocal<T> in an ASP.NET application.

ASP.NET utilises thread-agility, meaning that the same request can potentially be handled by several threads. To be safe you’d need to break encapsulation and store your items in the current HttpContext, rather than using ThreadStatic or ThreadLocal<T>:

internal static class DataHolder
{
    internal static ClassName PropertyName
    {
        get { return (ClassName)System.Web.HttpContext.Current.Items["foo"]; }
        set { System.Web.HttpContext.Current.Items["foo"] = value; }
    }
}

Unfortunately this thread-agility “feature” is very poorly documented. I’m reasonably sure that the thread switch can only happen at certain points in the lifecycle, not arbitrarily, so depending on exactly how and where in the lifecycle the code is used you might be safe with ThreadStatic or ThreadLocal<T>.

I’ll try to dig out some links…