Onlangs, toen ik aan een project werkte, moesten sommige pagina's veel data laden, en soms klikte ik op de pagina zonder te wachten tot de pagina klaar was geladen, en klikte ik daarna weer op een andere pagina
Er zal een zeer langzame toestand van suspensie zijn tijdens het laden van de webpagina, dus laten we het vandaag goed bestuderen.
In het begin dacht ik dat deze situatie op veel websites zou voorkomen of dat mijn computernetwerksnelheid zou zijn, maar ik merkte dat deze site dit probleem niet had; soms bleef ik hangen als ik iets plaatste, maar ik klikte op andere pagina's in het tabblad om snel te laden.
Laten we vandaag eens beter kijken!! De code die als eerste werd getest:
Homeview-code:
Controllercode:
Voor testcode-analyse heeft onze controller 3 methoden: één is de startpagina en de andere twee zijn testmethoden
Het Test1-verzoek blokkeert 5 seconden en geeft vervolgens de data terug aan de gebruiker
Test2-verzoeken blokkeren niet en geven gegevens direct terug aan de gebruiker
Onze homepage heeft twee interfaces voor Ajax-verzoeken, die asynchrone verzoeken zijn, dus er is geen blokkeringsprobleem.
We zullen zien dat Test1-methode pas content produceert nadat Test2 content heeft uitgegeven (Normaal gesproken zal de pagina de inhoud die door Test2 wordt teruggegeven direct uitvoeren, en dan 5 seconden wachten om de inhoud van Test1 te geven, omdat js niet blokkeert）
Vervolgens openen we direct de Test1- en Test2-interfaces, eerst Test1, en vervolgens meteen Test2, en ontdekken dat Test2 moet wachten tot Test1 is voltooid, zoals weergegeven in de onderstaande figuur:
Als een paginaverzoek een lezerslot instelt, kunnen andere verzoeken die tegelijkertijd in dezelfde sessie worden verwerkt de sessiestatus niet bijwerken, maar ze kunnen in ieder geval gelezen worden. Als een pagina een schrijfslot voor de sessiestatus aanvraagt, worden alle andere pagina's geblokkeerd, ongeacht of ze content willen lezen of schrijven. Als bijvoorbeeld twee programmaweergaven tegelijkertijd inhoud schrijven in dezelfde sessie, moet het ene programma wachten tot het andere programma klaar is voordat het geschreven kan worden. Bij AJAX-programmeren is het belangrijk om hiervan op de hoogte te zijn.
Speciale opmerking: Alleen bij het schrijven van een sessie blokkeer Asp.net het verzoek, maar zolang je de pagina hebt bezocht waar de sessie is geschreven, zoals de operatie na het inloggen op het systeem met de sessie (de sessie is natuurlijk vergrendeld tot hij verloopt, het is alleen zo dat de SessionID hetzelfde is). Er zal dit probleem zijn.
Netizen-informatie
Zolang de website een sessie gebruikt, vergrendelt elk verzoek de sessie gedurende de hele levensduur, zodat verzoeken met dezelfde sessionid moeten wachten om te worden ontgrendeld
Dit betekent dat als de website een time-out pagina heeft, deze niets kan doen en je moet wachten tot de time-out pagina laadt.
Je kunt het ook niet, meerdere ajax-verzoeken gelijktijdig op dezelfde pagina, je kunt het niet, berichtpollingverzoeken.
Om het samen te vatten:Als je een sessie naar het verzoek neemt, als je geen sessie naar het verzoek brengt, zal bovenstaande situatie niet optreden
Oplossing:
De functie SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly) toegevoegd aan de controllercontroller
Notitie:
Vereist betekent dat je een exclusieve vergrendeling op Session aanvraagt (dus geen parallelle verwerking van verzoeken voor dezelfde sessionID)
ReadOnly betekent dat je een niet-exclusieve lock op Session aanvraagt (d.w.z. je verzoek moet nog steeds wachten tot verzoeken met een exclusieve lock klaar zijn, maar je kunt verzoeken met niet-exclusieve vergrendelingen verwerken, maar je kunt verzoeken verwerken met niet-exclusieve vergrendelingen parallel. Het is echter aan jou om ervoor te zorgen dat je code niet naar Session wordt geschreven. Het wordt niet per se door het kader gehandhaafd)
ReadOnly betekent dat de sessie die je aanvraagt een niet-exclusieve lock is (d.w.z. je verzoek moet nog wachten op voltooiing, het verzoek om een exclusieve lock, maar je kunt een verzoek verwerken met een parallelle niet-exclusieve lock). Maar je wilt er wel voor zorgen dat je code geen sessies schrijft. Het hoeft niet door het framework uitgevoerd te worden)
|
Geplaatst op 22-09-2017 17:32:59
|
|
|
|
Huisbaas