Angel, Philip, ASP .Net requests can be handled either synchronously or asynchronously. If you are handling requests via instances of the Page class, then your requests are processed synchronously.
For the duration of a synchronous call, the entire request is handled on one thread. ASP .Net will not "move" your request to a different thread -- there is no benefit to doing this, and only the possibility for confusion. An excellent place to put the kind of contextual state you are describing is in the instance of your HttpApplication-derived class. You can do this in your global.asax file, or in a real class file. (You'll still need to have a global.asax file, which identifies your own class as the base class.) You can then gain access to this information through the ApplicationInstance property, or through the Context.ApplicationInstance property, which you'll need to cast to your derived class. All of this works great. Also, putting your state in a class derived from HttpApplication gives you a chance to hook any of the ASP .Net pipeline stages, and also to be notified (via Dispose) when you need to clean up state (such as disposing of database connections, etc.). The ASP .Net environment handles creating instances of the HttpApplication-derived class. It pools these instances; in a high-volume server, there are usually only a handful of instances of this class, one for each request in flight, plus a fudge factor. Instances of the class are associated with a particular HTTP request (including the HttpContext, HttpRequest, and HttpResponse), and are not dissociated until the request completes. If you need to gain access to this class from code that is not running in a class derived from HttpApplication, Page, UserControl, WebRequest, etc. then you can simply use ((MyApplication) HttpContext.Current.ApplicationInstance). Works like a champ. -- arlie -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Angel "Java" Lopez Sent: Saturday, April 24, 2004 7:11 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Thread in ASP.NET, ThreadStatic, Thread Pool 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 DevelopMentorR 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 =================================== 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
