Nylig, da jeg jobbet med et prosjekt, måtte noen sider laste inn mye data, og noen ganger klikket jeg på siden uten å vente på at siden skulle bli ferdig med å laste, og så klikket jeg på en annen side igjen
Det vil være en veldig langsom tilstand av suspendert animasjon under lasting av nettsiden, så la oss studere det nøye i dag.
Først trodde jeg at denne situasjonen ville oppstå på mange nettsteder eller et problem med datanettverkets hastighet, men jeg oppdaget at denne siden ikke hadde denne situasjonen, noen ganger satt jeg fast når jeg postet, men jeg klikket på andre sider i fanen for å laste raskt.
La oss ta en nærmere titt i dag!! Koden testet først:
Homeview-kode:
Kontrollerkode:
For testkodeanalyse har kontrolleren vår tre metoder, én er startsiden, og de to andre er testmetoder
Test1-forespørselsblokker i 5 sekunder og returnerer deretter data til brukeren
Test2-forespørsler blokkerer ikke og returnerer data direkte til brukeren
Vår hjemmeside har to grensesnitt for Ajax-forespørsler, som er asynkrone forespørsler, så det er ingen blokkeringsproblemer.
Vi vil finne at Test1-metoden bare gir innhold etter at Test2 har levert innhold (Normalt vil siden sende ut innholdet som returneres av Test2 direkte, og deretter vente 5 sekunder før innholdet returnert av Test1, fordi js ikke blokkerer）
Deretter får vi direkte tilgang til Test1- og Test2-grensesnittene, først til Test1, og deretter umiddelbart til Test2, og finner ut at Test2 må vente til Test1 er tilbake for å fullføre, som vist i figuren under:
Hvis en sideforespørsel setter en leserlås, vil andre forespørsler som behandles samtidig i samme økt ikke kunne oppdatere sesjonstilstanden, men de kan i det minste leses. Hvis en side ber om en skrivelås for sesjonstilstanden, blokkeres alle andre sider, uavhengig av om de vil lese eller skrive innhold. For eksempel, hvis to programvisninger skriver innhold i samme økt samtidig, må ett program vente til det andre programmet er ferdig før det kan skrives. I AJAX-programmering er det viktig å være oppmerksom på at dette skjer.
Spesiell merknad: Kun når du skriver en sesjon, vil Asp.net blokkere forespørselen, men så lenge du har besøkt siden der sesjonen er skrevet, for eksempel operasjonen etter at du logget inn i systemet med sesjonen (sesjonen er låst til den utløper, selvfølgelig, det er bare slik at SessionID-en er den samme). Det vil oppstå dette problemet.
Informasjon om nettbrukere
Så lenge nettstedet bruker en økt, vil hver forespørsel låse sesjonen gjennom hele dens levetid, slik at forespørsler med samme sessionid må vente på å låses opp
Dette betyr at hvis nettsiden har en tidsbegrenset side, kan den ikke gjøre noe, og du må vente på at den tidsbegrensede siden skal lastes.
Du kan heller ikke gjøre det, flere samtidige ajax-forespørsler på samme side, du kan ikke gjøre det, meldingspolling-forespørsler.
For å oppsummere:Hvis du tar en økt til forespørselen, hvis du ikke bringer en sesjon til forespørselen, vil ikke den ovennevnte situasjonen inntreffe
Løsning:
Lagt til funksjonen SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly) i kontrollerkontrolleren
Notat:
Required betyr at du ber om en eksklusiv lås på Session (dvs. ingen parallell behandling av forespørsler for samme sessionID)
ReadOnly betyr at du ber om en ikke-eksklusiv lås på Session (dvs. forespørselen din må fortsatt vente på forespørsler med eksklusiv lås for å fullføres, men du kan behandle forespørsler med ikke-eksklusive låser parallelt. Men det er opp til deg å sørge for at koden din ikke skrives til Session. Det håndheves ikke nødvendigvis av rammeverket)
ReadOnly betyr at sesjonen du ber om er en ikke-eksklusiv lås (dvs. forespørselen din må fortsatt vente på fullføring, forespørselen om en eksklusiv lås, men du kan behandle en forespørsel med en parallell ikke-eksklusiv lås). Men du vil være sikker på at koden din ikke skriver økter. Det trenger ikke å utføres av rammeverket)
|
Publisert på 22.09.2017 17:32:59
|
|
|
|
Vert