Session v ASP.NET

Je kdo, ki bi mi znal pomagat ?

@NavadniNimda: Beep. Nepopoln odgovor.

Če ima stran @Page atribut Session="ReadOnly", potem je možno iz Session seznama samo brati, pri čemer pa ni serializacije dostopov, temveč se uporablja reader-writer vzorec zaklepanja: to pomeni, da lahko več tako označenih strani istočasno dobi isto instanco objekta, saj se med seboj ne blokirajo. Seveda, če je vsebina seznama shranjena po metodi InProc. Če uporabljaš karkoli drugega, razen InProc sistema shranjevanja instanc objektov, potem morajo biti objekti označeni kot Serializable, njihovo spreminjanje pa sledi neki drugi logiki.

Če je objekt spremenljiv (mutable) oziroma če ne uporablja sinhronizacije, potem so težave praktično zagotovljene. Najlažje se jim je izogniti z uporabo vzorca copy-on-write. Narediš kopijo stanja, jo po potrbi dopolniš, nato pa originalno vrednost nadomestiš s kopijo (novimi podatki). Nekoliko potratno s pomnilnikom, ampak predvidljivo, enostavno in predvsem varno za uporabo.

@King80: Tako kot si jo opisal, je tvoja rešitev čisto OK. Kaj ti daje slab občutek, da morda nekaj ni prav?

Hm... sicer bi moral poznati strukturo aplikacije, ki jo izdeluješ, vendar pa se mi zdi, da poskušaš narediti navigacijo po drevesu.

Če to delaš na eni sami .aspx strani (npr. navigacija po katalogu tipov artiklov), potem lahko morda izkoristiš ViewState, pa se ti bo ta vrednost prenašala preko HTML-ja (skrito INPUT polje z ViewState podatki).

Če pa je to skupna komponenta za več strani (npr. navigacija po spletnem mestu), pa razmisli, če jo lahko izločiš v .master stran in potem na njej uporabiš ViewState.

Pri temu pa samo razmisli, če je smiselno uporabljati ViewState, saj ti bo ta dal na vsako zahtevo in odgovor še vse podatke, ki jih drevo v določenem trenutku vsebuje. Kar pomeni, da bodo zahteve po velikosti precej narasle, posledično pa bi odzivnost strani upadla.

Session je tako smotrno uporabiti, kadar postane ViewState večji od nekaj kB, saj s tem odplača nekaj več kode in konstantne porabe pomnilnika na strežniku z veliko večjo odzivnostjo spletnega mesta. V tem primeru pa poglej tudi to, da ViewState-a na komponenti ne uporabljaš (privzeto je vključen), saj boš s tem povezavo po nepotrebnem obremenjeval (višja latenca == slabša odzivnost).

Kar se pa tiče izgradnje celotnega drevesa v trenutku, ko se seja vzpostavlja, pa bi moral vedeti, če se to veže tudi na avtentikacijo (prijavo uporabnika). Če drevo gradiš šele po avtentikaciji (prijavi), potem ga je smiselno v celoti zgraditi že pri samem procesu prijave, čeprav bo to pomenilo krajši zastoj zaradi trajanja izdelave. Smiselno pa je to zato, ker je to zadnja točka, kjer bo uporabnik še toleriral sekundo ali celo dve sekundi pavze. Od prijave naprej pa morajo zadeve teči hitro in gladko.

@BlueRunner: za Session vemo, da se vsi requesti izvajajo na istem threadu, torej je serializacija že implicitna, odnosno ni pod vprašanjem. Za kompleksnejše R/w interakcije pa je prav gotovo potrebno izstresti iz rokava še kak trik, sicer se strežnik hitro odzove s kakšnim vetom. :)

King80: prosim nehaj komplicirati in daj TreeView objekt v Session kot si si zamislil in kot ti je nakazal BlueRunner. Vsi objekti so thread-varni, če ne pišeš v njih. Tule je pa njihov edini lastnik Session, ki laufa na enem threadu, torej so varni tudi, če pišeš v njih. Ko shranjuješ objekt se shrani le pointer, torej je tvoje prvotno vprašanje popolnoma rešeno (in se ni za bati, da boš imel počasno kodo zaradi tega).

Sem ubogal vaše nasvete, dal moje gradnike v Session in stvarca dela tako kot je treba.

Imam pa še eno butasto vprašanje :
je dobro dati tudi database connection v Session in se potem sklicevati na Session, ko ga rabim, ali pa je čisto OK, če je Connection "javen" ???

Hvala in lep pozdrav