Äskettäin, kun työskentelin projektin parissa, joidenkin sivujen piti ladata paljon dataa, ja joskus klikkasin sivua odottamatta sivun latautumista, ja sitten klikkasin taas toista sivua
Sivun latauksen aikana animaatio on hyvin hidas, joten tutkitaan sitä tarkasti tänään.
Aluksi ajattelin, että tämä tilanne tapahtuisi monilla verkkosivuilla tai tietokoneverkon nopeusongelmassa, mutta huomasin, ettei tällä sivustolla ollut tällaista tilannetta; joskus jäin jumiin postauksessa, mutta klikkasin muita sivuja välilehdellä latatakseni nopeasti.
Katsotaanpa tarkemmin tänään!! Ensimmäisenä testattu koodi:
Homeview-koodi:
Ohjainkoodi:
Testikoodin analysointiin ohjaimellamme on kolme menetelmää: yksi on kotisivu ja kaksi muuta testimenetelmiä
Test1-pyyntö esittää 5 sekunniksi ja palauttaa sitten tiedot käyttäjälle
Test2-pyynnöt eivät estä ja palauttavat tiedot suoraan käyttäjälle
Kotisivullamme on kaksi rajapintaa Ajax-pyynnöille, jotka ovat asynkronisia pyyntöjä, joten esto-ongelmaa ei ole.
Huomaamme, että Test1-menetelmä tuottaa sisältöä vasta sen jälkeen, kun Test2 tuottaa sisältöä (Normaalisti sivu tuottaa suoraan Test2:n palauttaman sisällön ja odottaa sitten 5 sekuntia ennen kuin Test1:n palauttama sisältö tulee ulos, koska js ei estä）
Sitten pääsemme suoraan Test1- ja Test2-rajapintoihin, ensin Test1:een ja sitten heti Test2:een, ja huomaamme, että Test2:n täytyy odottaa, että Test1 palaa valmiiksi, kuten alla olevassa kuvassa näkyy:
Jos sivupyyntö asettaa lukituslukon, muut samassa istunnossa samanaikaisesti käsiteltävät pyynnöt eivät pysty päivittämään istuntotilaa, mutta ainakin ne voidaan lukea. Jos sivu pyytää kirjoituslukitusta istuntotilalle, kaikki muut sivut estetään, riippumatta siitä, haluavatko ne lukea vai kirjoittaa sisältöä. Esimerkiksi, jos kaksi ohjelmanäkymää kirjoittavat sisältöä samassa istunnossa samanaikaisesti, toisen ohjelman on odotettava, että toinen ohjelma on valmis, ennen kuin se voidaan kirjoittaa. AJAX-ohjelmoinnissa on tärkeää olla tietoinen tästä tapahtumasta.
Erityishuomautus: Vain istuntoa kirjoittaessa Asp.net estää pyynnön, mutta niin kauan kuin olet käynyt sivulla, jossa istunto kirjoitetaan, esimerkiksi toiminnossa kirjautumisen jälkeen järjestelmään istunnon kanssa (istunto on lukittu siihen asti, kunnes se vanhenee, tietysti vain SessionID on sama). Tämä ongelma tulee olemaan.
Nettitietoa
Niin kauan kuin verkkosivusto käyttää istuntoa, jokainen pyyntö lukitsee istunnon koko elinkaarensa ajan, joten saman sessionid-tunnuksen pyyntöjen on odotettava avautumista
Tämä tarkoittaa, että jos sivustolla on aikakatkaisu sivu, se ei voi tehdä mitään, ja sinun täytyy odottaa, että ajastettu sivu latautuu.
Et voi tehdä sitäkään, useita ajax-samanaikaisia pyyntöjä samalla sivulla, et voi tehdä sitä, lähetä viestikyselyt.
Yhteenvetona:Jos otat istunnon pyynnölle, jos et tuo istuntoa pyyntöön, yllä mainittu tilanne ei synny
Ratkaisu:
Lisätty SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly) -ominaisuus ohjaimen ohjaimeen
Muistiinpano:
Pakollinen tarkoittaa, että pyydät yksinoikeudella lukittua Session-järjestelmää (eli ei saman sessionID:n pyyntöjen rinnakkaista käsittelyä)
ReadOnly tarkoittaa, että pyydät ei-yksinoikeudellista lukitusta Sessionille (eli pyyntösi täytyy silti odottaa, että yksinoikeudella lukittu pyyntö valmistuu, mutta voit käsitellä ei-yksinoikeudellisia pyyntöjä lukitukset rinnakkain. Sinun tehtäväsi on kuitenkin varmistaa, ettei koodisi kirjoita Sessionille. Se ei välttämättä ole kehikon valvonnassa)
ReadOnly tarkoittaa, että pyytämäsi istunto on ei-yksinoikeudellinen lukitus (eli pyyntösi joutuu silti odottamaan valmistumista, eli pyynnön on käsiteltävä rinnakkaisella ei-eksklusiivisella lukolla). Mutta haluat varmistaa, ettei koodisi kirjoita istuntoja. Sitä ei tarvitse suorittaa kehysjärjestelmässä)
|
Julkaistu 22.9.2017 17.32.59
|
|
|
|
Vuokraisäntä