tag:blogger.com,1999:blog-17332816.post113090518742265969..comments2023-04-05T22:38:04.960+08:00Comments on Cup(Of T): ThreadStatic, CallContext and HttpContext in ASP.Netpiers7http://www.blogger.com/profile/11186470645521299750noreply@blogger.comBlogger24125tag:blogger.com,1999:blog-17332816.post-49980769379677135042014-05-06T23:40:06.034+08:002014-05-06T23:40:06.034+08:00Hi Piers,
Is this still true with 4.5 and using S...Hi Piers,<br /><br />Is this still true with 4.5 and using Set/GetLogicalData on the CallContext?Dewyhttps://www.blogger.com/profile/08803286448368181478noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-6873238456954444142012-09-07T07:27:02.411+08:002012-09-07T07:27:02.411+08:00I'm looking at similar behaviour under .NET 4....I'm looking at similar behaviour under .NET 4.5 / IIS Express 8.<br /><br />If anyone is looking to try to reproduce it, make sure you're using IIS or IIS Express and not Cassini (the built in web server) because Cassini is extremely different.<br /><br />For me, a thread context variable is set during BeginRequest, and the thread sometimes changes between there and the handling of the request. My options appear to be (a) don't do it, or (b) try to make sure it happens right before the request is processed so there's more chance that it will stay.JThttps://www.blogger.com/profile/07390855177809507380noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-62800037134423150712012-04-19T08:04:07.600+08:002012-04-19T08:04:07.600+08:00中華民國虛擬總統: 7 years later, given you're almost c...中華民國虛擬總統: 7 years later, given you're almost certainally not using a single core PC, it's going to be hard to reproduce under the same level of trival load. Try ramping it up a bit (a lot). Also, the threshold for request queuing / handoff has probably been tuned a fair bit between ASP.Net 2 and 4.piers7https://www.blogger.com/profile/11186470645521299750noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-69040370576327857932012-04-19T02:56:57.736+08:002012-04-19T02:56:57.736+08:00I've conducted my own test using the same slow...I've conducted my own test using the same slow/fast page concept in .NET 4.0 but wasn't able to see any thread switching behavior. The only time I can make it happen it's when I mark the page as Async and use AddOnPreRenderCompleteAsync to add my own being/end request handler. In summary, thread switching happens in an async operation is perfectly understandable and the author needs to publish how he made it happen in a synchronous operation.中華民國虛擬總統https://www.blogger.com/profile/08442726666651408318noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-20771651122406047542011-09-22T12:03:38.073+08:002011-09-22T12:03:38.073+08:00Very informative and unleashed article Thanks and ...Very informative and unleashed article Thanks and the all the comments.I am a newbie in this type of problem. kindly someone explain me How can I do it with .net framework 4 in WebApplication.I want to store my EntityFrameWork context I want to ensure it one context per request not share context..Any Help would be appreciable.. ThanksAnonymoushttps://www.blogger.com/profile/00872558380399945338noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-12406154315613053192011-04-11T15:10:01.116+08:002011-04-11T15:10:01.116+08:00Good to read this. Well written post. Thanks a lot...Good to read this. Well written post. Thanks a lot!PHP Web Developmenthttp://www.vinfotech.com/web-development/php-web-development.htmnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-81684856831641126262011-03-11T00:38:14.160+08:002011-03-11T00:38:14.160+08:00One alternative option for ThreadStatic type behav...One alternative option for ThreadStatic type behavior that only lasts the length of a request is a follows:<br /><br /> - Create Custom IPrinciple and IIdentity Classes.<br /> - Add a property to one of these that contains a Dictionary of objects<br /> - Each request at the PostAuthenticateRequest stage, replace the existing Principle with the custom Principle (you can easily just wrap the existing one to retain the values)<br /> (Set Thread.CurrentPrincipal AND the HttpContext.Current.User to the new principal object)<br /><br />After this, you can access your dictionary in a non webspecific way by: ((CustomPrincipal)Thread.CurrentPrincipal).MyDictionary<br /><br />It seems like a bit of work up front, but it really is not too bad, and performs well. The advantage of this method is that:<br /> - The dictionary will only last the length of the ThreadContext (i.e. the length of a request). There is no need to manually clean at the end<br /> - ASP.Net takes care of transferring the Principal to any new threads if the thread changes for a request<br /> - .Net takes care of transferring a reference to the principal to all child threads, this is available from child threads also.<br /><br />I have used this method successfully before. Once the initial pain of implementing this pattern, I really never had to think about much again - it just seems to work.Jim Toasthttp://whythelongid.netnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-40603480449456193182011-02-18T19:17:22.026+08:002011-02-18T19:17:22.026+08:00I guess you could use the IPrincipal as your user-...I guess you could use the IPrincipal as your user-singleton if you wanted to, but it would tie your business objects to knowing about a particular IPrincipal (or at least a particular interface), so I'm not convinced its a great solution.oscommerce developmenthttp://www.anylinuxwork.com/technology/open-source-development/oscommerce.htmlnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-14229988569576068692011-01-19T19:20:37.164+08:002011-01-19T19:20:37.164+08:00I was also looking at Thread.CurrentPrincipal, but...I was also looking at Thread.CurrentPrincipal, but I shyed away due to SQL Server Windows auth and CAS issues. For simplicity's sake I'd rather developers know their code is running in a single configurable service account, with a business-domain-specific CurrentRequest.Ecommerce developerhttp://www.ecommerce-web-developers.comnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-27860531828397105892010-06-29T21:07:02.175+08:002010-06-29T21:07:02.175+08:00What do you do in case HttpContext.Current is null...What do you do in case HttpContext.Current is null? <br /><br />If you need the information stored in it, how do you gain access to it?<br /><br />RegardsAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-46277606140231875682010-02-09T17:58:10.990+08:002010-02-09T17:58:10.990+08:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-17605705659080366452009-08-29T17:26:08.213+08:002009-08-29T17:26:08.213+08:00Nice Post
Informative and useful one
I am .Net Dev...Nice Post<br />Informative and useful one<br />I am .Net Developer and I am looking for this<br />Thanks for the great stuff.Nimesh – Perception Systemhttp://www.perceptionsystem.com/noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-92092860875855986932009-07-09T00:44:41.974+08:002009-07-09T00:44:41.974+08:00This comment has been removed by the author.Serhiyhttps://www.blogger.com/profile/05811752428686017296noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-9229026419809085362009-03-10T18:56:00.000+09:002009-03-10T18:56:00.000+09:00Thanks for your article, and solution which i will...Thanks for your article, and solution which i will now use, really appreciate it and can't see much in the way of MS docs on this. I think it is stupid that asp.net even allows the "static" keyword - why would you ever need it? Really it should be configurable so you can change the meaning of your statics to what you need, with the default being per-request. The only reason i can think of for not doing this is too hard to implement, which is a crappy reason for making life difficult for everyone! This is a hangover from c++ single threaded pre web apps, and should have been brought into the 21st century by now.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-26743829687622988662008-12-17T08:34:00.000+09:002008-12-17T08:34:00.000+09:00Hi Jeffim working on a business framework shared b...Hi Jeff<BR/><BR/>im working on a business framework shared between web and windows applications<BR/><BR/>im in need to store objects like facades and searched for thread based solutions coz these objects lifecycle is bound to the executing thread<BR/><BR/>these facades are created for the httprequest or windows lifetime and i ve no need to share them with other threads<BR/><BR/>i thought callcontext was for me the best way in my study case <BR/><BR/>doing a little search on the web bring me to ur post and i didnt find anything wrong about callcontext in ur post<BR/><BR/>is there in ur opinion anything wrong in using callcontext to do that ?<BR/><BR/>thx for ur replyAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-52279329910481483092008-12-17T08:33:00.000+09:002008-12-17T08:33:00.000+09:00Hi,im working on a business framework shared betwe...Hi,<BR/><BR/>im working on a business framework shared between web and windows applications<BR/><BR/>im in need to store objects like facades and searched for thread based solutions coz these objects lifecycle is bound to the executing thread<BR/><BR/>these facades are created for the httprequest or windows lifetime and i ve no need to share them with other threads<BR/><BR/>i thought callcontext was for me the best way in my study case <BR/><BR/>doing a little search on the web bring me to ur post and i didnt find anything wrong about callcontext in ur post<BR/><BR/>is there in ur opinion anything wrong in using callcontext to do that ?<BR/><BR/>thx for ur replyAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-42383153716408740312008-12-04T08:41:00.000+09:002008-12-04T08:41:00.000+09:00piers7, am trying to reproduce the same scenario (...piers7, am trying to reproduce the same scenario (Thread switching), which is discussed. I am using Asp.net 2.0 (AS.net development server). From your log it is clear that the issue is reproducible. But i could not able to do that in 2.0? Can you please confirm that it is not the problem in 2.0. Also it would be helpful if you can post your code with which you able to reproduce.<BR/><BR/>Thanks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-9990678798124494302008-04-10T08:25:00.000+08:002008-04-10T08:25:00.000+08:00]] Do you consider that this is a case where threa...]] Do you consider that this is a case where threaStatic is OK?<BR/><BR/>Maybe, but I'd probably still avoid it, for a couple of reasons:<BR/><BR/>Primarily, leaving your connection instances floating about like this is a resource drain. Expensive resources like this should be released as early as possible, not just left open for the duration. Ok, so it's only 20 connections, but imagine if everyone did that.<BR/><BR/>You've also got to be very careful about keeping the connection instances 'unsullied': avoid using SQL context, certain security schemes etc... I've seen this thread-connection-reuse scheme combine with a transaction leak to bring down an entire system (rather than just a certain request always bombing out, which would have been easier to diagnose).<BR/><BR/>And you've still got the issue that the connection instance you start with in the HTTPHandlers isn't neccesarily the one you use in your Page_Load etc... so woe betide you if you try and use a transaction that spans the two (though, for various reasons, this would be a bad thing to do anyway).piers7https://www.blogger.com/profile/11186470645521299750noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-41944377846352921382008-04-08T09:44:00.000+08:002008-04-08T09:44:00.000+08:00I am using threadstatic field to store my Connecti...I am using threadstatic field to store my Connection object.<BR/><BR/>The idea is that all conection objects are the same in all threads but I need them to be thread static to make sure that the connection object is not use simultaneous for opening two datareaders for example. <BR/><BR/>So I don´t care in which thread a request is procesed since all thread have a smilar connection. What is important to me is that the same connection is not use to do two or more task at the same time.<BR/><BR/>Do you consider that this is a case where threaStatic is OK?Unknownhttps://www.blogger.com/profile/04087441833719331275noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-13666643555141453032007-12-20T01:10:00.000+09:002007-12-20T01:10:00.000+09:00Wow, what a pain. I am so glad I found this post ...Wow, what a pain. I am so glad I found this post though - I thought I was going crazy. Thank you.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-1164993241985856022006-12-02T01:14:00.000+08:002006-12-02T01:14:00.000+08:00I just got bit by this myself. I am using .NET 2....I just got bit by this myself. I am using .NET 2.0. I have changed by code to use HttpContext. Fun fun.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17332816.post-1155466158161482972006-08-13T18:49:00.000+08:002006-08-13T18:49:00.000+08:00We're still using the UserContext approach I sugge...We're still using the UserContext approach I suggested above. This is just a class that delegates to CallContext or HttpContext depending on if HttpContext is available or not.<BR/><BR/>Putting this class in it's own assembly prevents the System.Web reference leakage.piers7https://www.blogger.com/profile/11186470645521299750noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-1134289105002906142005-12-11T16:18:00.000+08:002005-12-11T16:18:00.000+08:00The Thread.CurrentPrincipal gets setup from the Ht...The Thread.CurrentPrincipal gets setup from the HttpContext.User in two different places: in HttpApplication.SetPrincipalOnThread, which fires after the authentication modules (if any) have done their work, and in HttpApplication.OnThreadEnter, which is what's called when a HttpApplication instance starts its execution, or resumes it's execution on a different thread.<BR/><BR/>So - as you'd expect - there's no issues with Thread.CurrentPrincipal being lost when you migrate to another thread, though if you've overwritten the Thread.CurrentPrincipal directly, rather than setting HttpContext.User then you're not going to get what you want.<BR/><BR/>I guess you could use the IPrincipal as your user-singleton if you wanted to, but it would tie your business objects to knowing about a particular IPrincipal (or at least a particular interface), so I'm not convinced its a great solution.piers7https://www.blogger.com/profile/11186470645521299750noreply@blogger.comtag:blogger.com,1999:blog-17332816.post-1134086221788606912005-12-09T07:57:00.000+08:002005-12-09T07:57:00.000+08:00Everything's 1.1 unless mentioned otherwise at the...Everything's 1.1 unless mentioned otherwise at the moment. Sorry I should have made that clearer.<BR/><BR/>You're right of course that this would apply to the Thread.CurrentPrincipal as well. From memory this gets setup at the end of OnAuthenticate, in which case it would have to be re-setup if the thread migrates in order not to get lost. I'll have another play...<BR/><BR/>The workaround we've been using is to store all per-user context in a UserContext object. This class just delegates storage either to Thread local storage, or to HttpContext.Items, depending on whether HttpContext.Current!=null. As a result this class insulates our business objects from having to know the mechanics of how per-user context is stored, and doesn't tie them to a web UI (so they can still participate in unit tests, even if there's no WinForms UI on the horizon).piers7https://www.blogger.com/profile/11186470645521299750noreply@blogger.com