What are best practices for using thread local storage in .NET?

Question

I have a requirement in my application that I think can be met by using thread local storage, but I'm wondering if it's one of those things that's best to avoid.

I have read a few articles on the subject:

http://www.dotnetcoders.com/web/Articles/ShowArticle.aspx?article=58

http://msdn.microsoft.com/en-us/library/system.threadstaticattribute(vs.80).aspx

I know how to use it, I'm just wondering if I should use it.

Any advice, gotchas to be aware of?

[Edit]

Here's the use case:

I funnel all data access through a few methods that do a lot of logging about each query. One thing I log is a complete dump of the command text with commands filled in so that I can simply copy-paste from my trace logs directly into Sql Management Studio.

Way up in global.asax in my web apps I send email to admins with as much information as I can when I get an unhandled exception. I want to put that sql command dump text into this email when I get a SqlException, which will save me the time of digging through trace logs when a page blows up because of a query.

I don't want to change the method signatures of my data access classes just so I can pass some reference all the way down the stack, just to get it out when I get an exception. I was thinking maybe TLS would be a good place to put something like "lastsqlcommand", but that's not looking like a viable solution.

Answer 1

A gotcha for asp.net applications: the processing of a single request might switch threads, namely if there are parallel requests in the same session. Because of this, anything you put in TLS before the HttpApplication.PostRequireRequestState event might not be there later, because you are on a different thread.

[Edit by the asker]

For my particular use case, I ended up adding a key-value pair to the SqlException.Data dictionary, which I then retrieve when I log the exception details. This gives me the functionality I was hoping to use thread local storage for.