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.
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.
Thread local storage is a quick way to fix a library that was designed before threads and uses a lot of global variables and statics. It's the way that the C standard library was made thread-safe while not changing its interface (internally, many functions use static buffers).
Generally, it's kind of good for that purpose. If you have to have global data in a multi-threaded environment, then thread-local storage is a good way to go. A common reason is that you are calling a third-party function that calls you back in the same stack-frame but doesn't give you a hook for passing extra information -- this happens a lot when you try to wrap older C libraries in .NET.
Have a look at new .net 4 ThreadLocal<T> class with an example, more info here.
来源：https://stackoverflow.com/questions/175129/what-are-best-practices-for-using-thread-local-storage-in-net