For nylig, da jeg arbejdede på et projekt, skulle nogle sider indlæse en masse data, og nogle gange klikkede jeg på siden uden at vente på, at siden var færdig med at indlæse, og så klikkede jeg på en anden side igen
Der vil være en meget langsom tilstand af suspenderet animation, mens websiden indlæses, så lad os studere det grundigt i dag.
Først troede jeg, at denne situation ville opstå på mange hjemmesider eller på mit computernetværks hastighedsproblem, men jeg fandt ud af, at denne side ikke havde denne situation; nogle gange sad jeg fast, når jeg postede, men jeg klikkede på andre sider i fanen for at indlæse hurtigt.
Lad os tage et nærmere kig i dag!! Koden testede først:
Homeview-kode:
Controller-kode:
Til testkodeanalyse har vores controller 3 metoder, én er startsiden, og de to andre er testmetoder
Test1-anmodningen blokerer i 5 sekunder og returnerer derefter data til brugeren
Test2-forespørgsler blokerer ikke og returnerer data direkte til brugeren
Vores hjemmeside har to grænseflader til Ajax-forespørgsler, som er asynkrone forespørgsler, så der ikke er noget blokeringsproblem.
Vi vil opdage, at Test1-metoden kun outputter indhold, efter Test2 outputter indhold (Normalt vil siden direkte outputte det indhold, Test2 returnerede, og derefter vente 5 sekunder med at outputte det indhold, Test1 returnerede, fordi js ikke blokerer）
Derefter går vi direkte til Test1- og Test2-grænsefladerne, vi tilgår først Test1, og derefter straks Test2, og finder ud af, at Test2 skal vente, indtil Test1 er tilbage for at fuldføre, som vist i figuren nedenfor:
Hvis en sideanmodning sætter en læserlås, vil andre forespørgsler, der behandles samtidig i samme session, ikke kunne opdatere sessionens tilstand, men de kan i det mindste læses. Hvis en side anmoder om en skrivelås for sessionstilstanden, blokeres alle andre sider, uanset om de ønsker at læse eller skrive indhold. For eksempel, hvis to programvisninger skriver indhold i samme session på samme tid, skal det ene program vente, til det andet program er færdigt, før det kan skrives. I AJAX-programmering er det vigtigt at være opmærksom på, at dette sker.
Særlig note: Kun når du skriver en session, vil Asp.net blokere anmodningen, men så længe du har besøgt siden, hvor sessionen er skrevet, såsom operationen efter at have logget ind i systemet med sessionen (sessionen er låst, indtil den udløber, det er kun tilfældet, at SessionID'et er det samme). Der vil være dette problem.
Netizen-information
Så længe hjemmesiden bruger en session, vil hver anmodning låse sessionen gennem hele dens levetid, så anmodninger med samme sessionid skal vente på at blive låst op
Det betyder, at hvis hjemmesiden har en side med tidsbegrænset tid, kan den ikke gøre noget, og du skal vente på, at den tidsbegrænsede side indlæses.
Du kan heller ikke gøre det, flere ajax-samtidige forespørgsler på samme side, du kan ikke gøre det, beskedafstemningsanmodninger.
For at opsummere det:Hvis du tager en session til anmodningen, hvis du ikke bringer en session til anmodningen, vil ovenstående situation ikke opstå
Opløsning:
Tilføjede SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)-funktionen til controllercontrolleren
Seddel:
Required betyder, at du anmoder om en eksklusiv lås på Session (dvs. ingen parallel behandling af anmodninger om samme sessionID)
ReadOnly betyder, at du anmoder om en ikke-eksklusiv lås på Session (dvs. din anmodning skal stadig vente på, at anmodninger med eksklusiv lås bliver færdige, men du kan behandle anmodninger med ikke-eksklusive låse parallelt. Det er dog op til dig at sikre, at din kode ikke skriver til Session. Det håndhæves ikke nødvendigvis af rammen)
ReadOnly betyder, at den session, du anmoder om, er en ikke-eksklusiv lås (dvs. din anmodning skal stadig vente på fuldførelse, anmodningen om en eksklusiv lås, men du kan behandle en anmodning med en parallel ikke-eksklusiv lås). Men du skal sikre dig, at din kode ikke skriver sessioner. Det behøver ikke at blive udført af frameworket)
|
Opslået på 22/09/2017 17.32.59
|
|
|
|
Udlejer