navn<\/em>“);<\/p>\n <\/p>\n
Hvis man s\u00e5ledes vil udskrive v\u00e6rdien af sessionsvariablen count, beh\u00f8ver man blot at skrive<\/p>\n
<\/p>\n
<%=Session(“count”);%><\/p>\n
<\/p>\n
Applikationsbaseret lagring<\/h1>\n
Man kan ogs\u00e5 v\u00e6lge at lagre information p\u00e5 applikationsbasis. Oplysninger, der\u00a0 lagres p\u00e5 denne m\u00e5de, vil v\u00e6re tilg\u00e6ngelige hele applikationens levetid. De oplysninger, man v\u00e6lger at opbevare p\u00e5 denne m\u00e5de, er typisk indstillinger om applikationen. Det kan eksempelvis v\u00e6re databaseadresser og anden ops\u00e6tning.<\/p>\n
Fordelen ved applikationsbaseret lagring er, at man kan n\u00f8jes med at opbevare oplysninger et sted, hvor de kan tilg\u00e5s af ASP-programmer i alle sessioner. Ved kun at opbevare dataene et sted, sparer man hukommelse p\u00e5 web-serveren \u2013 plads som man i stedet kan bruge til at h\u00e5ndtere flere sessioner samtidigt og derved give brugerne kortere svartider.<\/p>\n
Selv om en af de store fordele ved applikationsbaseret lagring s\u00e5ledes er, at dataene opbevares et sted, er dette ogs\u00e5 en af de st\u00f8rste ulemper. Hvis man har mange aktive sessioner samtidigt, risikerer man, at sessionerne l\u00e6ser og \u00e6ndrer applikationsvariablerne samtidigt. Man kan eksempelvis forestille sig nedenst\u00e5ende ASP-dokument, der bliver udf\u00f8rt i to sessioner samtidigt.<\/p>\n
<\/p>\n
L\u00e6s applikationsvariablen A<\/p>\n
L\u00e6g en til applikationsvariablen A<\/p>\n
Gem v\u00e6rdien i applikationsvariablen A<\/p>\n
<\/p>\n
Da web-servere sj\u00e6ldent har liges\u00e5 mange processorer, som der er samtidige sessioner, bliver ASP-kode fra flere sessioner afviklet p\u00e5 samme tid. Det betyder, at man ikke kan v\u00e6re sikker p\u00e5, at en session bliver afviklet f\u00e6rdig, f\u00f8r den n\u00e6ste bliver afviklet. Hvis ASP-programmet fra ovenst\u00e5ende eksempel bliver hentet i to forskellige sessioner p\u00e5 samme tid, kan programlinierne blive afviklet i nedenst\u00e5ende r\u00e6kkef\u00f8lge. Det antages, at applikationsvariablen A ved start har v\u00e6rdien 2.<\/p>\n
<\/p>\n
Session 1: L\u00e6s applikationsvariablen A (A er 2)<\/p>\n
Session 2: L\u00e6s applikationsvariablen A (A er 2)<\/p>\n
Session 2: L\u00e6g 1 til applikationsvariablen A (hvilket giver v\u00e6rdien 3)<\/p>\n
Session 2: Gem v\u00e6rdien i applikationsvariablen A (A er nu 3)<\/p>\n
Session 1: L\u00e6g 1 til applikationsvariablen A (Session 1 har tidligere l\u00e6st A til at v\u00e6re 2, og resultatet af denne beregning er derfor 3)<\/p>\n
Session 1: Gem v\u00e6rdien i applikationsvariablen A (A er nu 3)<\/p>\n
<\/p>\n
Resultatet af de 2 sessioner er s\u00e5ledes, at applikationsvariablen A f\u00e5r v\u00e6rdien 3, selv om det jo er tydeligt, at den skulle have haft v\u00e6rdien 4.<\/p>\n
Dette problem kaldes en race condition<\/em>. En race condition opst\u00e5r, n\u00e5r to eller flere sessioner fors\u00f8ger at \u00e6ndre de samme variabler samtidigt, og resultatet kommer an p\u00e5 den r\u00e6kkef\u00f8lge, sessionerne blev afviklet i. Som det ses, skal race conditions undg\u00e5s.<\/p>\nI ASP er der mekanismer til at undg\u00e5 disse problemer. Man kan l\u00e5se applikationsvariablerne, s\u00e5 man forhindrer andre sessioner i at tilg\u00e5 dem samtidigt. N\u00e5r der kun er en session, som kan \u00e6ndre variablerne ad gangen, er der ingen problemer. Man er s\u00e5ledes sikker p\u00e5 den r\u00e6kkef\u00f8lge sessionerne bliver afviklet i. Nedenst\u00e5ende eksempel viser, hvilken r\u00e6kkef\u00f8lge man er garanteret, at ovenst\u00e5ende eksempel bliver afviklet i.<\/p>\n
<\/p>\n
Session 1: L\u00e5s applikationsvariablerne<\/p>\n
Session 1: L\u00e6s applikationsvariablen A (A er 2)<\/p>\n
Session 1: L\u00e6g 1 til applikationsvariablen A (hvilket giver v\u00e6rdien 3)<\/p>\n
Session 1: Gem v\u00e6rdien i applikationsvariablen A (A er nu 3)<\/p>\n
Session 1: Frigiv applikationsvariablerne<\/p>\n
Session 2: L\u00e5s applikationsvariablerne<\/p>\n
Session 2: L\u00e6s applikationsvariablen A (A er 3)<\/p>\n
Session 2: L\u00e6g 1 til applikationsvariablen A (hvilket giver v\u00e6rdien 4)<\/p>\n
Session 2: Gem v\u00e6rdien i applikationsvariablen A (A er nu 4)<\/p>\n
Session 2: Frigiv applikationsvariablerne<\/p>\n
<\/p>\n
Som det ses, f\u00e5r A nu den rigtige v\u00e6rdi: 4.<\/p>\n
Man skal dog v\u00e6re p\u00e5passelig med at l\u00e5se applikationsvariablerne. N\u00e5r de er l\u00e5st, er det ikke muligt for andre sessioner at tilg\u00e5 dem, og man kan derfor risikere, at en lang r\u00e6kke sessioner ikke kan afsluttes, fordi en session har l\u00e5st applikationsvariablerne. Man skal derfor aldrig l\u00e5se applikationsvariablerne i l\u00e6ngere tid end h\u00f8jst n\u00f8dvendigt. Hvis programmet tillader det, kan man med fordel l\u00e6gge alle sine referencer til applikationsvariablerne i samme blok, og derved n\u00f8jes med at l\u00e5se dem en gang.<\/p>\n