Nyligen, när jag arbetade med ett projekt, behövde vissa sidor ladda mycket data, och ibland klickade jag på sidan utan att vänta på att sidan skulle ladda klart, och klickade sedan på en annan sida igen
Det kommer att vara ett mycket långsamt tillstånd av suspenderad animation när webbsidan laddas, så låt oss studera det noggrant idag.
Först trodde jag att den här situationen skulle uppstå på många webbplatser eller problem med min dators nätverkshastighet, men jag upptäckte att den här sidan inte hade samma situation, ibland fastnade jag när jag postade, men jag klickade på andra sidor i fliken för att ladda snabbt.
Låt oss ta en närmare titt idag!! Koden som testades först:
Homeview-kod:
Kontrollkod:
För testkodsanalys har vår controller tre metoder, en är startsidan och de andra två är testmetoder
Test1-förfrågan blockerar i 5 sekunder och returnerar sedan data till användaren
Test2-förfrågningar blockerar inte och returnerar data direkt till användaren
Vår startsida har två gränssnitt för Ajax-förfrågningar, som är asynkrona förfrågningar, så det finns inget blockeringsproblem.
Vi kommer att se att Test1-metoden bara ger innehåll efter att Test2 har producerat innehåll (Normalt kommer sidan att rapportera innehållet som returneras av Test2 direkt, och sedan vänta 5 sekunder för att skicka ut innehållet som Test1 returnerar, eftersom js inte blockerar）
Sedan går vi direkt åt Test1- och Test2-gränssnitten, vi går först till Test1, och sedan omedelbart till Test2, och upptäcker att Test2 måste vänta tills Test1 återvänder för att slutföra, som visas i figuren nedan:
Om en sidförfrågan sätter ett läslås kan andra förfrågningar som behandlas samtidigt i samma session inte uppdatera sessionstillståndet, men åtminstone kan de läsas. Om en sida begär ett skrivlås för sessionstillståndet blockeras alla andra sidor, oavsett om de vill läsa eller skriva innehåll. Till exempel, om två programvyer skriver innehåll i samma session samtidigt, måste det ena programmet vänta tills det andra är klart innan det kan skrivas. I AJAX-programmering är det viktigt att vara medveten om att detta händer.
Särskild notering: Endast när du skriver en session blockerar Asp.net förfrågan, men så länge du har besökt sidan där sessionen skrivs, till exempel operationen efter att du loggat in i systemet med sessionen (sessionen är låst tills den går ut, det är bara så att SessionID:t är detsamma). Det kommer att finnas ett problem.
Information om nätanvändare
Så länge webbplatsen använder en session kommer varje förfrågan att låsa sessionen under hela dess livstid, så att förfrågningar med samma sessionid måste vänta på att låsas upp
Det betyder att om webbplatsen har en tidsbegränsad sida kan den inte göra något, och du måste vänta på att den tidsbestämda sidan ska laddas.
Du kan inte heller göra det, flera samtidiga ajax-förfrågningar på samma sida, du kan inte göra det, skicka meddelandepolling-förfrågningar.
Sammanfattningsvis:Om du tar en session till begäran, om du inte tar med en session till begäran, kommer ovanstående situation inte att inträffa
Lösning:
Lade till funktionen SessionState(System.Web.SessionState.SessionState.ReadOnly) i kontrollerkontrollern
Not:
Required betyder att du begär ett exklusivt lås på Session (dvs. ingen parallell bearbetning av förfrågningar om samma session-ID)
ReadOnly betyder att du begär ett icke-exklusivt lås på Session (dvs. din begäran måste fortfarande vänta på att förfrågningar med exklusivt lås ska bli klara, men du kan behandla förfrågningar med icke-exklusiva lås parallellt. Men det är upp till dig att se till att din kod inte skriver till Session. Det är inte nödvändigtvis upprätthållet av ramverket)
ReadOnly betyder att sessionen du begär är ett icke-exklusivt lås (dvs. din begäran måste fortfarande vänta på att slutföras, begäran om ett exklusivt lås men du kan behandla en förfrågan med ett parallellt icke-exklusivt lås). Men du vill vara säker på att din kod inte skriver sessioner. Det behöver inte utföras av ramverket)
|
Publicerad på 2017-09-22 17:32:59
|
|
|
|
Hyresvärd