Nemrég, amikor egy projekten dolgoztam, néhány oldalnak sok adatot kellett betöltenie, és néha rákattintottam az oldalra anélkül, hogy megvártam volna, amíg az oldal betöltődik a betöltés, majd újra rákattintottam egy másik oldalra
Az oldal betöltése közben nagyon lassú felfüggesztett animáció lesz, ezért ma alaposan tanulmányozzuk.
Eleinte azt hittem, hogy ez a helyzet sok weboldalon előfordul vagy a számítógépes hálózati sebességproblémám, de rájöttem, hogy ezen az oldalon nincs ilyen, néha elakadtam posztoláskor, de gyorsan betöltődtem a fül más oldalaira.
Nézzük meg ma közelebbről!! A kód először tesztelte:
Homeview kód:
Vezérlő kód:
A tesztkód elemzéshez a vezérlőnknek három módszere van: az egyik a kezdőlap, a másik kettő tesztmódszerek
A Test1 kérés 5 másodpercig blokkolja, majd visszaadja az adatokat a felhasználónak
A Test2 kérések nem blokkolnak, és közvetlenül a felhasználónak adják vissza az adatokat
A kezdőlapunkon két interfész van az Ajax kérésekhez, amelyek aszinkron kérések, így nincs blokkolási probléma.
Azt fogjuk tapasztalni, hogy a Test1 módszer csak akkor ad tartalmat kiadni, ha a Test2 tartalmat ad (Általában az oldal közvetlenül a Test2 által visszaküldött tartalmat adja ki, majd 5 másodpercet vár, hogy a Test1 által visszaküldött tartalmat adja ki, mert a js nem blokkolja）
Ezután közvetlenül elérjük a Test1 és Test2 interfészeket, először a Test1-et, majd azonnal a Test2-t, és azt találjuk, hogy a Test2-nek várnia kell, amíg a Test1 visszatér, hogy befejezzék, ahogy az alábbi ábrán is látható:
Ha egy oldalkérés olvasó-zárlatot állít be, akkor a más, ugyanabban az ülésben egyszerre feldolgozó kérések nem tudják frissíteni a munkafolyamat állapotát, de legalább olvashatók. Ha egy oldal írási zárolást kér a session állapotához, akkor minden más oldal blokkolódik, függetlenül attól, hogy olvasni vagy írni akar tartalmat. Például, ha két programnézet egyszerre ír tartalmat ugyanabban az ülésben, az egyik programnak meg kell várnia, amíg a másik program befejeződik, mielőtt megírhatnánk. Az AJAX programozásban fontos tudatában lenni ennek a megtörténésnek.
Külön megjegyzés: Csak akkor ír egy ülést, Asp.net blokkolja a kérést, de amennyiben már meglátogattad azt az oldalt, ahol az ülés íródott, például a műveletet a rendszerbe való bejelentkezés után, amely a szekcióval együtt (a szekció le van zárva, amíg lejár, persze, csak akkor van az, ha a SessionID ugyanaz). Lesz ez a probléma.
Netélő információk
Amíg a weboldal egy ülést használ, minden kérés végig zárja a játékmenetet, így ugyanazzal a sessioniddel rendelkező kéréseknek várniuk kell a feloldásra
Ez azt jelenti, hogy ha a weboldalnak van időzített oldala, nem tud semmit csinálni, és várnod kell, amíg az időzített oldal betöltődik.
Te sem teheted meg, több Ajax párhuzamos kérés ugyanazon az oldalon, nem tudod, üzenetszavazási kérések.
Összefoglalva:Ha egy ülést veszel a kéréshez, ha nem hozol részt a kéréshez, a fenti helyzet nem fog bekövetkezni
Megoldás:
Hozzáadtam a SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly) funkciót a vezérlővezérlőhöz
Jegyzet:
A kötelező azt jelenti, hogy exkluzív zárolást kérsz a Session-en (azaz nem kell párhuzamosan feldolgozni ugyanazt a sessionID-t kérve).
ReadOnly azt jelenti, hogy nem exkluzív zárolást kérsz a Session-en (azaz a kérésnek még mindig várnia kell, hogy exkluzív zárolású kérések befejeződjenek, de a nem exkluzív kéréseket is feldolgozhatod párhuzamosan zár. Viszont rajtad múlik, hogy a kódod ne írjon a Session-be. Ez nem feltétlenül a keretrendszer által érvényesíthető)
A ReadOnly azt jelenti, hogy az általad kért ülés nem exkluzív zárolás (azaz a kérésnek még várnia kell a befejezésre, az exkluzív zárolás kérése, de feldolgozhatod a kérést párhuzamos nem exkluzív zárolóval). De ügyelj arra, hogy a kódod ne írjon üléseket. Nem kell a keretrendszer végrehajtania)
|
Közzétéve 2017. 09. 22. 17:32:59
|
|
|
|
Háziúr