Hi people! Thanks Merril!
Some comments: > There is no inherent reason that multiple calls for the same request must be made on the same thread, but it might not happen unless you have a heavily loaded web server. It should not matter to you (except as a matter of curiosity) whether multiple threads could be used to handle a single request; you should not be doing anything that would break if it happened, and AFAIK there is no reason to do so. Well, I need to use an object (a persistence class, a transaction coordinator, or a unit of work, for example), and I don't want to pass to every other object that needs it. I want to retrieve the object, like a "thread singleton". The ThreadStatic attribute resolves the problem. But if the ASP.NET thread pool behaviour can change the thread, the ThreadStatic is no sense. The intented code is something like: mythreadsingleton = CreateThreadSingletonAndStoreInThreadStaticVariable(); mythreadsingleton.BeginTransaction(); // a lot of work with business object that use GetThreadSingleton(), and I don't pass the object // to every method mythreadsingleton.EndTransaction(); But if all that code is on the thread launched by ASP.NET, on a request, and ASP.NET can change the thread between the .BeginTransaction, and .EndTransaction, or can reuse the thread in between, ooopppss!!! :-) I have no evidence (documentation, etc...) that the thread can be used or changed during the life of a request (I refer "request" as the single execution of a page, any other execution of the same or other page, for me, is another request). > The apparent intent of the designers is that you use the Items property of the HttpContext object to store any state you need during execution of the request. Ok, but I want that the persistence class works on other envirnoments, not only web. For now, I can use a test on null to HttpContext.Current, to determine if I am in a web app. > In what class had you planned to use ThreadStatic variables? Even if all the calls for a particular request were guaranteed to be made on the same thread (and they're not), there could be calls made on that same thread for a new request before all calls for an earlier request had been completed. The ASP.NET infrastructure was designed to support more simultaneously executing requests than there are threads -- using ThreadStatic variables just isn't appropriate. Hmmm... I think that the thread pool is used: one request, one thread, and DURING THE LIFE of the request, the thread is for the request. That is the behaviour on others server (on open source, for example, Tomcat). Where is the documentation of the behavoir??? Is an ASP.NET behaviour?? Or is a behaviour of .NET thread pool?? Angel "Java" Lopez http://www.ajlopez.com/ =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
