[Šaltinis] ASP.NET skirtumas tarp "ThreadStatic", "CallContext" ir "HttpContext"

Summary:
Net jei manote, kad žinote, ką darote, nėra saugu saugoti ką nors ThreadStatic naryje, CallContext ar Thread vietinėje saugykloje ASP.Net programoje, jei yra galimybė kad reikšmė gali būti nustatyta prieš Page_Load (pvz., IHttpModule arba puslapio konstruktoriuje), bet pasiekiama per arba po jo.

[Atnaujinimas: Rugpjūtis 2008 Atsižvelgiant į gana didelį skaičių žmonių ir toliau nuorodą į šį pranešimą jaučiu poreikį paaiškinti, kad šis temų apsikeitimo elgesys vyksta labai konkrečiu tašku puslapyje gyvenimo ciklą, o ne tada, kai jis jaučiasi. Mano formuluotė po Jef Newson citatos buvo apgailėtina. Be to, buvau be galo patenkintas (ir pamalonintas) kiek kartų mačiau šį įrašą cituojamas dizaino diskusijose apie tinkamą elgesį su HttpContext. Džiaugiuosi, kad žmonėms tai buvo naudinga.]

Yra daug painiavos dėl to, kaip ASP.Net įdiegti konkrečius vartotojo vienetus, t. y. globalius duomenis, kurie yra globalūs tik vienam vartotojui ar užklausai. Tai nėra neįprastas reikalavimas: skelbti operacijas, saugumo kontekstą ar kitus "globalius" duomenis vienoje vietoje, o ne stumti juos per kiekvieną metodą, kaip gali padaryti tramp duomenys švaresnis (ir lengviau skaitomas) įgyvendinimas. Tačiau tai puiki vieta šaudyti sau į koją (ar galvą), jei nesate atsargūs. Maniau, kad žinau, kas vyksta, bet nežinojau.

Pageidautina parinktis, saugoti savo singletons HttpContext.Current.Items, yra paprasta ir saugi, tačiau susieja aptariamą singleton su naudojimu ASP.Net programoje. Jei vienišas jūsų verslo objektas yra žemyn, tai nėra idealu. Net jei nuosavybės prieigą įvyniosite į if sakinį

... tada jūs vis dar turite nuorodą System.Web iš to surinkimo, kuris linkęs įterpti daugiau "webby" objektų netinkamoje vietoje.

Alternatyvos yra naudoti [ThreadStatic] statinį narį, Thread vietinę saugyklą (kuri beveik prilygsta tam pačiam dalykui) arba CallContext.

[ThreadStatic] problemos yra gerai dokumentuotos, bet apibendrinant:
Lauko initalizeriai šaudo tik ant pirmosios gijos
ThreadStatic duomenis reikia aiškiai išvalyti (pvz., EndRequest), nes kol Thread yra pasiekiama, ThreadStatic duomenys nebus GC'd, todėl galite nutekėti išteklius.
ThreadStatic duomenys yra tik bet koks geras per užklausą, nes kita užklausa gali ateiti į kitą giją, ir gauti kažkieno duomenis.
Scottas Hanselmanas teisingai supranta, kad "ThreadStatic" nežaidžia gerai su ASP.Net, bet iki galo nepaaiškina, kodėl.

Saugykla CallContext palengvina kai kurias iš šių problemų, nes kontekstas miršta užklausos pabaigoje ir GC atsiras galiausiai (nors vis tiek galite nutekėti išteklius, kol GC atsitiks, jei jūs saugote vienkartinius daiktus). Be to, CallContext yra tai, kaip HttpContext saugomas, todėl jis turi būti gerai, tiesa?. Nepriklausomai nuo to, jūs manote, kad (kaip ir aš), kad su sąlyga, kad jūs išvalyti po savęs kiekvieno prašymo pabaigoje, viskas būtų gerai:
"Jei inicijuojate ThreadStatic kintamąjį užklausos pradžioje ir teisingai tvarkyti nurodytą objektą užklausos pabaigoje, aš rizikuočiau teigti, kad nieko blogo nenutiks

"Dabar,Galiu klysti. CLR gali nustoti talpinti giją įpusėjus, kažkur serijizuoti jos krūvą, suteikti jai naują krūvą ir leisti jai pradėti vykdyti。 Aš tuo labai abejoju. Manau, kad tai įmanoma, kad hyperthreading taip pat būtų sunku, bet aš taip pat abejoju. ”

Džefas Newsomas

"Jei inicijuojate ThreadStatic kintamąjį užklausos pradžioje, ir jūs tinkamai atsikratyti nurodyto objekto užklausos pabaigoje, aš ketinu išeiti ant galūnės ir teigti, kad nieko blogai nutiks. Jūs netgi šaunus tarp kontekstų tame pačiame "AppDomain"

"Dabar galiu klysti. CLR potencialiai galėtų sustabdyti valdomą giją, kažkur išleisti jos krūvą, suteikti jai naują krūvą ir leisti jai pradėti vykdyti. Aš rimtai abejoju. Manau, kad galima įsivaizduoti, kad hiperthreading taip pat apsunkina situaciją, bet aš taip pat tuo abejoju."
Džefas Newsomas

Update: This was the misleading bit. I do explain further later on that this thread-swap can only happen between the BeginRequest and the Page_Load, but Jef's quote creates a very powerful image I failed to immediately correct. My bad.

Taigi tam tikru momentu ASP.NET nusprendžia, kad yra per daug I/O gijų, apdorojančių kitas užklausas. [...] Jis tiesiog priima užklausą ir įtraukia ją į eilę šiame vidiniame eilės objekte per ASP.NET vykdymo laiką. Tada, kai tai bus eilėje, I/O gija paprašys darbininko gijos, o tada I/O gija bus grąžinta į savo telkinį. [...] Taigi ASP.NET turės tą darbuotojo giją, apdoroti užklausą. Jis pereis į ASP.NET vykdymo laiką, kaip ir I/O gija esant mažai apkrovai.

Dabar aš visada žinojau apie tai, bet maniau, kad tai įvyko pakankamai anksti, kad man nerūpėjo. Tačiau atrodo, kad klydau. Mes turėjome problemą mūsų ASP.Net programoje, kai vartotojas spustelėja vieną nuorodą tik spustelėjęs kitą, ir mūsų programa susprogdina su nulinės nuorodos išimtimi vienam iš mūsų singletons (aš naudoju CallContext ne ThreadStatic singleton, bet pasirodo, kad tai nesvarbu).

Aš padariau šiek tiek tyrimų apie tai, kaip tiksliai ASP. Net's threading darbai, ir gavo prieštaringų nuomonių-maskuojamas-kaip-faktas (prašymai yra siūlai-judrus per prašymą vs prašymai yra prisegti prie gijos jų gyvenimą), todėl aš atkartoti mano problema bandomojoje programoje su lėtu puslapiu (sekundę miega) ir greitu puslapiu. Paspaudžiu lėto puslapio nuorodą ir prieš grįžtant puslapiui paspaudžiu greito puslapio nuorodą. Rezultatai (log4net sąvartynas apie tai, kas vyksta) mane nustebino.

Išvestis rodo, kad antrosios užklausos atveju BeginRequest įvykiai HttpModule sraute ir puslapio konstruktorius suveikia vienoje gijoje, bet Page_Load suveikia kitoje. Antroji gija turėjo HttpContext perkeltas iš pirmojo, bet ne CallContext ar ThreadStatic's (NB: kadangi HttpContext yra saugomas CallContext, tai reiškia, kad ASP.Net yra aiškiai perkeliant HttpContext). Leiskite tik paaiškinti tai dar kartą:

• Gijos perjungiamos sukūrus IHttpHandler
• Paleidus puslapio lauko iniciatorių ir konstruktorių
• Po bet kokių BeginRequest, AuthenticateRequest, AquireSessionState tipo įvykių, kuriuos naudoja Global.ASA/IHttpModules.
• Tik HttpContext perkeliamas į naują giją.
  

Gijos perjungimas įvyksta sukūrus IHttpHandler
Paleidus puslapio lauko iniciatorius ir konstruktorius
Po bet kokių BeginRequest, AuthenticateRequest, AquireSessionState tipo įvykių, kuriuos naudoja jūsų Global.ASA / IHttpModules.
Tik HttpContext perkeliamas į naują giją.

[3748] INFORMACIJA 11:10:05,239 ASP. Global_asax. Application_BeginRequest() - BEGIN /ConcurrentRequestsDemo/SlowPage.aspx
[3748] INFORMACIJA 11:10:05,239 ASP. Global_asax. Application_BeginRequest() - threadid=, threadhash=, threadhash(now)=97, calldata=
[3748] INFORMACIJA 11:10:05,249 ASP. SlowPage_aspx.. ctor() - threadid=3748, threadhash=(cctor)97, threadhash(now)=97, calldata=3748, logicalcalldata=3748
[3748] INFORMACIJA 11:10:05,349 ASP. SlowPage_aspx. Page_Load() - threadid=3748, threadhash=(cctor)97, threadhash(now)=97, calldata=3748, logicalcalldata=3748
[3748] INFORMACIJA 11:10:05,349 ASP. SlowPage_aspx. Page_Load() - Lėtas puslapio miegas....

[2720] INFORMACIJA 11:10:05,669 ASP. Global_asax. Application_BeginRequest() - BEGIN /ConcurrentRequestsDemo/FastPage.aspx
[2720] INFORMACIJA 11:10:05,679 ASP. Global_asax. Application_BeginRequest() - threadid=, threadhash=, threadhash(now)=1835, calldata=
[2720] INFORMACIJA 11:10:05,679 ASP. FastPage_aspx.. ctor() - threadid=2720, threadhash=(cctor)1835, threadhash(now)=1835, calldata=2720, logicalcalldata=2720, threadstatic=2720

[3748] INFORMACIJA 11:10:06,350 ASP. SlowPage_aspx. Page_Load() - Lėtas puslapio pabudimas....
[3748] INFORMACIJA 11:10:06,350 ASP. SlowPage_aspx. Page_Load() - threadid=3748, threadhash=(cctor)97, threadhash(now)=97, calldata=3748, logicalcalldata=3748
[3748] INFORMACIJA 11:10:06,350 ASP. Global_asax. Application_EndRequest() - threadid=3748, threadhash=97, threadhash(now)=97, calldata=3748
[3748] INFORMACIJA 11:10:06,350 ASP. Global_asax. Application_EndRequest() - END /ConcurrentRequestsDemo/SlowPage.aspx

[4748] INFORMACIJA 11:10:06,791 ASP. FastPage_aspx. Page_Load() - threadid=2720, threadhash=(cctor)1835, threadhash(now)=1703, calldata=, logicalcalldata=, threadstatic=
[4748] INFORMACIJA 11:10:06,791 ASP. Global_asax. Application_EndRequest() - threadid=2720, threadhash=1835, threadhash(now)=1703, calldata=
[4748] INFORMACIJA 11:10:06,791 ASP. Global_asax. Application_EndRequest() - END /ConcurrentRequestsDemo/FastPage.aspx

Pagrindinis dalykas yra tai, kas atsitinka, kai "FastPage" Page_Load suveikia. ThreadID yra 4748, bet threadID, kurį saugojau HttpContext ctor, yra 2720. Loginės gijos maišos kodas yra 1703, bet tas, kurį išsaugojau ctor, yra 1835. Visi duomenys, kuriuos saugojau CallContext, dingo (net ir pažymėti ILogicalThreadAffinative), bet HttpContext vis dar yra. Kaip ir tikėjotės, mano "ThreadStatic" taip pat nebėra.

HttpContext.Current.Items
https://www.itsvse.com/thread-4501-1-1.html