[C#] Sessie niet laten verlopen

[PdeBie]

Hey allen,

voor mijn web-applicatie speelt de volgende situatie:
gebruikers gaan naar het orderformulier om een order in te voeren. Terwijl ze dit doen komt er een klant in de winkel waardoor ze weg zijn van de pc. Na enige tijd komen ze terug bij de pc en blijkt de sessie verlopen, waardoor ze de order opnieuw moeten invoeren. Dit wil ik proberen af te vangen, zodat de sessie niet verloopt.

Ik dacht eerst om de sessie-timeout te verhogen, maar dit bleek niet afdoende helaas. Dus had ik het volgende idee. Ik zet een hidden img tag op m'n orderformulier die middels javascript om de x minuten gerefreshed wordt. Deze afbeelding staat op een aparte pagina die bij elke call in de sessie iets wegschrijft, waardoor de sessie open blijft. Echter lijkt dit niet goed te werken.

Hoe werkt het?
Afbeelding op een html met daarbij de volgende javascript:

JavaScript:

setInterval( "loadAntiTimeoutImage()", 120000 ); //refresh image every 2 minutes

function loadAntiTimeoutImage() {
    //load a page to set a session variable to prevent timeouts
    $('#hiddenTimeOutImage').attr("src", '~/TimeoutImage.aspx?t=' + getDate());
}

function getDate() {
    var dateTimeInfo = new Date();
    var year = dateTimeInfo.getYear();
    var month = dateTimeInfo.getMonth() + 1;
    var date = dateTimeInfo.getDate();
    var hours = dateTimeInfo.getHours();
    var minutes = dateTimeInfo.getMinutes();
    var seconds = dateTimeInfo.getSeconds();
    return year + "-" + month + "-" + date + " " + hours + ":" + minutes + ":" + seconds;
}

Om caching van de afbeelding te voorkomen heb ik een cache-killer op de url gezet d.m.v. de functie getDate op de querystring te zetten.
In de code-behind van de pagina die ik aanroep (TimeoutImage.aspx) staat het volgende:

C:

protected void Page_Load(object sender, EventArgs e)
    {
        Random rand = new Random(5000);
        Session["TimeoutImage"] = rand.Next();
    }

Als ik debug, zie ik de debugger netjes in de Page_Load komen en wordt de sessie variabele keurig overschreven. Toch lijkt dit de sessie niet in leven te houden helaas. Iemand een idee?

[RobIII]

Waarom gebruik je überhaupt nog een sessietimeout als je 'm toch niet wil laten verlopen? Kinda defeats the purpose, niet? En waarom zet je 'm niet gewoon op een dag bijvoorbeeld?
En waarom lig je te klooien met images als je gewoon AJAX kunt gebruiken?

[PdeBie]

RobIII schreef op maandag 01 augustus 2011 @ 11:56:
Waarom gebruik je überhaupt nog een sessietimeout als je 'm toch niet wil laten verlopen? Kinda defeats the purpose, niet? En waarom zet je 'm niet gewoon op een dag bijvoorbeeld?
En waarom lig je te klooien met images als je gewoon AJAX kunt gebruiken?

Hoe schakel ik die session timeout in IIS uit dan?
Kan ik deze gewoon weg laten in de web.config?

De imagetruc gebruik ik als 'tip' van een collega. Echter is hij nu met vakantie en mijn kennis van AJAX is niet sterk genoeg. Wat voor advies heb je?

[alwinuzz]

pdebie schreef op maandag 01 augustus 2011 @ 11:44:
Ik dacht eerst om de sessie-timeout te verhogen, maar dit bleek niet afdoende helaas.

Waarom niet?

Je kan de session timeout verhogen in web.config. Maximum is 1 jaar. Let op dat er een verschil is tussen session en authentication (zijn gebruikers ingelogd als ze een order plaatsen?)

[PdeBie]

alwinuzz schreef op maandag 01 augustus 2011 @ 12:13:
[...]

Waarom niet?

Had dit al gedaan, alleen het leek niet te werken. Dit hadden we ingesteld op 8 uur (werkdag) en getest op een aparte machine. Helaas reageerde het formulier nergens meer op, toen we na een paar uur (binnen de 8 uur) weer begonnen te klikken. Lijkt alsof de sessie weg is.

alwinuzz schreef op maandag 01 augustus 2011 @ 12:13:
Let op dat er een verschil is tussen session en authentication (zijn gebruikers ingelogd als ze een order plaatsen?)

Authentication time out had ik nog niet van gehoord. Dit ga ik eens nader onderzoeken, maar het lijkt erop dat de gebruiker nog wel correct is ingelogd. De rest van de omgeving werkt nog wel naar behoren namelijk.


Ik ben trouwens nog wel benieuwd naar het AJAX verhaal waar RobIII over begon.

even ter extra info: dit verhaal speelt zich af in een DotNetNuke omgeving.

[Vae Victis]

pdebie schreef op maandag 01 augustus 2011 @ 13:32:
[...]


Had dit al gedaan, alleen het leek niet te werken. Dit hadden we ingesteld op 8 uur (werkdag) en getest op een aparte machine. Helaas reageerde het formulier nergens meer op, toen we na een paar uur (binnen de 8 uur) weer begonnen te klikken. Lijkt alsof de sessie weg is.

Verhoog ook je application timeout, anders word na bv 20 minuten je application gestopt en daarmee ook je lopende sessies.

[edit]Zit bij de instellingen van je application pool (maak een nieuwe aan als de huidige door meerdere sites word gebruikt).
En dan bij advanced settings/process model/Idle Time-out (minutes)

[ Voor 16% gewijzigd door Vae Victis op 01-08-2011 13:40 ]

[TJHeuvel]

Wellicht kan je overwegen om uberhaupt geen sessies te gebruiken, maar dit soort informatie in je database op te slaan. Gegarandeert dat het blijft leven, totdat je het zelf leeg gooit.

Daarnaast klinkt het refreshen van een image als een behoorlijk vieze hack.

[ Voor 17% gewijzigd door TJHeuvel op 01-08-2011 13:38 ]

[eek]

Je kan ook 'last' hebben van een application recycle. Misschien handig om gebruik te maken van de StateServer (MSDN: Session-State Modes), deze heeft daar namelijk geen last van.

[ Voor 9% gewijzigd door eek op 01-08-2011 16:38 ]

[PdeBie]

Vae Victis schreef op maandag 01 augustus 2011 @ 13:37:
[...]

Verhoog ook je application timeout, anders word na bv 20 minuten je application gestopt en daarmee ook je lopende sessies.

[edit]Zit bij de instellingen van je application pool (maak een nieuwe aan als de huidige door meerdere sites word gebruikt).
En dan bij advanced settings/process model/Idle Time-out (minutes)

Dank je, hier zal ik nog eens naar kijken.

TJHeuvel schreef op maandag 01 augustus 2011 @ 13:37:
Wellicht kan je overwegen om uberhaupt geen sessies te gebruiken, maar dit soort informatie in je database op te slaan. Gegarandeert dat het blijft leven, totdat je het zelf leeg gooit.

Daarnaast klinkt het refreshen van een image als een behoorlijk vieze hack.

De applicatie is helaas al te ver gevorderd om nu nog sessies er uit te halen. Het refreshen van een image was ook inderdaad een laatste noodgreep. Ik zou het ook liever gewoon op applicatiebasis regelen, echter is mijn kennis nog niet toereikend genoeg

eek schreef op maandag 01 augustus 2011 @ 16:38:
Je kan ook 'last' hebben van een application recycle. Misschien handig om gebruik te maken van de StateServer (MSDN: Session-State Modes), deze heeft daar namelijk geen last van.

Klopt, hier was ik dan weer wel mee bekend. Deze heb ik als volgt ingesteld:

code:

<sessionState timeout="600" mode="InProc" />

De timeout van de sessionState staat nu ingesteld op 10 uur. De application timeout heb ik op hetzelfde ingesteld. Ben benieuwd of het nu beter gaat.

[ Voor 22% gewijzigd door PdeBie op 02-08-2011 09:03 ]

[PdeBie]

--- dubbel post ---

[ Voor 97% gewijzigd door PdeBie op 02-08-2011 09:03 . Reden: dubbelpost ]

[PolarBear]

pdebie schreef op dinsdag 02 augustus 2011 @ 08:54:

Klopt, hier was ik dan weer wel mee bekend. Deze heb ik als volgt ingesteld:

code:

<sessionState timeout="600" mode="InProc" />

De timeout van de sessionState staat nu ingesteld op 10 uur. De application timeout heb ik op hetzelfde ingesteld. Ben benieuwd of het nu beter gaat.

Ehm, dit is niet de instelling voor een state server (maar in process).

[PdeBie]

weet ik. We wilden eerst kijken of het op te lossen was binnen de application pool etc.

[__fred__]

Ik zou je ernstig willen adviseren om, indien je een professionele webapplicatie maakt, om StateServer of SQLServer mode voor je session state te gebruiken:

Voordelen:

• Na een recycle van je application pool, leeft je session state nog steeds. Recycling van de application pool kan om allerlei redenen gebeuren, bijvoorbeeld crashes van de pool, te weinig geheugen, inactivity timeouts, scheduled recycles etc. Je krijgt hier nooit vat op. Bij elke recycle van de pool is je session state weg.
• Je applicatie wordt veel schaalbaarder. Ineens kun je sessionstate delen tussen servers en round-robin achtige DNS toepassen om load te verdelen, of servers uit je farm halen. etc. Je hoeft niet meer offline voor windows updates met twee servers, etc.
• Je kunt je applicatie, indien de objecten die je in de sessie stopt, niet zijn veranderd, in place upgraden. De sessie blijft bewaard, en na de update van je applicatie draait de gebruiker vrolijk verder.

Nadelen:

• Alle objecten die je in je sessie stopt, moeten Serializable zijn. Als je daar niet vanaf het begin rekening mee hebt gehouden, kan het een bitch zijn om dat voor elkaar te krijgen.

[PdeBie]

dank je wel.
de applicationpool oplossing heeft helaas niet geholpen. We gaan nu inderdaad SQLserver mode gebruiken voor het opslaan van de Sessies.

Misschien even uitzoek werk hoe dit werkt, maar gaat goed komen.

[HansvDr]

Waarom niet gewoon een cookie gebruiken met een geldigheid van x aantal uur?

[R4gnax]

HansvDr schreef op dinsdag 02 augustus 2011 @ 16:51:
Waarom niet gewoon een cookie gebruiken met een geldigheid van x aantal uur?

Omdat ASP.NET WebForms sessies niet zo simpel in elkaar steken.

[D-Raven]

pdebie schreef op dinsdag 02 augustus 2011 @ 08:54:

De applicatie is helaas al te ver gevorderd om nu nog sessies er uit te halen. Het refreshen van een image was ook inderdaad een laatste noodgreep. Ik zou het ook liever gewoon op applicatiebasis regelen, echter is mijn kennis nog niet toereikend genoeg


[...]

Dat bedoeld hij niet. Hij bedoeld dat je het in plaats van in je sessie, in de database opslaat. Je kunt het dan alsnog cachen in je sessie, maar dan is het in ieder geval niet zo erg meer dat je sessie expired of whatever.

[PdeBie]

D-Raven schreef op dinsdag 02 augustus 2011 @ 20:38:
[...]


Dat bedoeld hij niet. Hij bedoeld dat je het in plaats van in je sessie, in de database opslaat. Je kunt het dan alsnog cachen in je sessie, maar dan is het in ieder geval niet zo erg meer dat je sessie expired of whatever.

ja klopt. Ik wist ook niet dat je de sessie variabelen ook in de database kon opslaan middels sessionState mode 'sqlserver'. Dit heb ik nu dus ontdekt en zijn we aan het inbouwen om te kijken of dit ons probleem verhelpt.

[D-Raven]

pdebie schreef op woensdag 03 augustus 2011 @ 08:52:
[...]


ja klopt. Ik wist ook niet dat je de sessie variabelen ook in de database kon opslaan middels sessionState mode 'sqlserver'. Dit heb ik nu dus ontdekt en zijn we aan het inbouwen om te kijken of dit ons probleem verhelpt.

Het zou kunnen dat je daar tegen een muur aanloopt, ik las dat er DotNetNuke gebruikt wordt. Als er modules zijn welke dingen in de sessie opslaat welke niet serializable zijn, dan ga je nat.

[PdeBie]

D-Raven schreef op woensdag 03 augustus 2011 @ 09:05:
[...]


Het zou kunnen dat je daar tegen een muur aanloopt, ik las dat er DotNetNuke gebruikt wordt. Als er modules zijn welke dingen in de sessie opslaat welke niet serializable zijn, dan ga je nat.

correct, daar lopen we nu dus tegenaan

Ik ga een voorstel doen voor een andere oplossing. Als de sessie is verlopen, een redirect doen naar een andere pagina met daarop de tekst 'sessie verlopen blablabla'.

[D-Raven]

pdebie schreef op woensdag 03 augustus 2011 @ 11:57:
[...]


correct, daar lopen we nu dus tegenaan

Ik ga een voorstel doen voor een andere oplossing. Als de sessie is verlopen, een redirect doen naar een andere pagina met daarop de tekst 'sessie verlopen blablabla'.

Volgens mij ben ik niet duidelijk genoeg, want je hebt het antwoord wat gegevens was verkeerd geinterpreteerd.

Je slaat nu je form waardes in je sessie op. Dit zorgt voor problemen. Sla ze dan in de database op en gebruik je sessie puur als cache voor deze gegevens.
Hiermee wordt dus bedoeld dat je de form waardes NIET in je sessie opslaat, maar in je database. We hebben het dus over de gegevens, en niet over je sessie, die je in je database wilt opslaan.

[PdeBie]

probleem is, is dat er in de code-behind objecten gevuld worden aan de hand van de formulier gegevens. Deze moet ik in de sessie opslaan, om later mee verder te kunnen. Het formulier wordt namelijk dynamisch opgebouwd aan de hand van de objecten.

Aangezien deze objecten niet serializable zijn gaat dit dus niet in de database helaas. Daar liep ik nu tegenaan.

De input van de gebruiker gaat gewoon de viewstate in. Dit is geen probleem. Het probleem ligt hem in de objecten die onder water gebruikt worden.

[R4gnax]

pdebie schreef op woensdag 03 augustus 2011 @ 11:57:
[...]

Ik ga een voorstel doen voor een andere oplossing. Als de sessie is verlopen, een redirect doen naar een andere pagina met daarop de tekst 'sessie verlopen blablabla'.

Zoiets als dit, bedoel je?

[PdeBie]

R4gnax schreef op woensdag 03 augustus 2011 @ 18:21:
[...]


Zoiets als dit, bedoel je?

haha grappig, die had ik gisteren ook gevonden

Nee, ik zat er over na te denken om hem gewoon naar de login pagina te sturen. Maar ik moet dit voorstel eerst in de groep gooien hier, want dat is een beslissing die ik niet zelf mag/kan maken, omdat dit de bediening van de applicatie behoorlijk beinvloed.

[HansvDr]

R4gnax schreef op dinsdag 02 augustus 2011 @ 17:09:
[...]

Omdat ASP.NET WebForms sessies niet zo simpel in elkaar steken.

Als ik zo iets maak sla ik 1 key op in een cookie, de rest in de database, gewoon in ASP.Net.

Of ik doe het via Membership, laat de gebruiker dus eerst inloggen en zorg dat de inlog niet verloopt.

[PdeBie]

ik ben dit artikel nog tegen gekomen op het internet en dit zijn we nu aan 't proberen:
http://www.dotnetcurry.com/ShowArticle.aspx?ID=453

In een lokaal testprojectje werkt dit naar behoren. Ben nu aan het kijken op de testomgeving van onze DotNetNuke omgeving of het daar ook werkt.

[R4gnax]

HansvDr schreef op donderdag 04 augustus 2011 @ 11:05:
[...]


Als ik zo iets maak sla ik 1 key op in een cookie, de rest in de database, gewoon in ASP.Net.

Of ik doe het via Membership, laat de gebruiker dus eerst inloggen en zorg dat de inlog niet verloopt.

Ik bedoelde dat het concept van een sessie in WebForms niet een simpele self-managed cookie is, maar een basisonderdeel in het hele WebForms framework waar (net als ViewState) een heleboel andere code ook op kan leunen.

Dat je jou stukje code kunt fixen door een 'sessie' ernaast te klussen lost het probleem voor die andere stukken code nog niet op. En zelfs als in andere code er op dat moment nog geen concrete problemen mee zijn, is het een heel goed idee de mogelijkheid dat het ooit wèl mis gaat meteen mee af te dekken. (Defensive programming, enzo.)

[Luuk1983]

Een aantal dingen zijn al eerder aangehaald, maar laat ik het even duidelijk formuleren:

• Je hebt in de web.config een session timout. Dit is de tijd waarna een session verloopt. Een session is een object dat in het geheugen van de server opgelagen wordt. Het is daarom over het algemeen niet wenselijk om een hele hoge session timout te gebruiken. Dit betekent namelijk dat het object in het geheugen van de server blijft totdat de timeout verstreken is. Bij elke request wordt de timeout weer gereset (als je 'sliding expiration') aan hebt staan.
• Als je inlogt heb je ook nog zoiets als de authentication timout. Als je niks met inloggen doet dan heb je hier niks mee te maken. Let op dat de authentication timeout bij een request pas gereset wordt nadat minimaal de helft van de tijd verstreken is (in tegenstelling tot de session timeout die meteen bij elke request gereset wordt).
• Je IIS worker process houdt ermee op als er (default) 20 minuten geen enkele activiteit heeft plaatsgevonden. Je kan je session timeouts nog zo hoog zetten, als het worker process ermee ophoudt dan heb je daar niks aan.

Natuurlijk heb je state servers of SQL databases om je sessies in op te slaan, maar dit heeft nadelen, zoals moeilijker onderhoud, performance (sql server is een stuk langzamer dan InProc bijv) of dat objecten serializable zijn. En volgens mij is het ook niet nodig.

De simpelste oplossing is simpelweg om regelmatig requests te doen zodat je sessie in leven blijft en je worker process in leven blijft. Dit kan door bijvoorbeeld een async call te doen naar een functie of een pagina (keep-alive.aspx?), zodat de gebruiker daar helemaal niks van merkt.

We hebben het wel eens zo opgelost bij één masterpage. Een (lege) WebMethode in de codebehind van de masterpage (WebMethodes zijn via AJAX aan te roepen):

C#:

/// <summary>
/// Function that can be called from AJAX to keep the session alive
/// </summary>
[WebMethod]
    public static void KeepAlive()
    {
        //This function doesn't need to do anything, just calling it through AJAX makes sure the session is kept alive
            ;
    }

En javascript:

JavaScript:

function keepAlive() {
    PageMethods.KeepAlive(KeepAliveSuccess);
}

function KeepAliveSuccess(result, eventArgs) {
}

function pageLoad() {
setInterval('keepAlive()', 60000);
}   

Let wel op dat de pageLoad() in dit geval automatisch door het AJAX framework aangeroepen wordt, mogelijk moet je dit zelf even anders doen. In bovenstaand voorbeeld wordt elke 60 seconden de javascript functie 'keepAlive()' aangeroepen, die op zijn beurt weer de PageMethode 'KeepAlive()' aanroept. En dat is de Methode in de code behind.

Een hele smerige, maar wel effectieve methode zou ook nog een iframe kunnen zijn met een pagina die een meta refresh heeft. Deze methode raadt ik zeker niet aan, maar het is wel een optie.

Hopelijk heb je hier wat aan

[Grijze Vos]

Als het niet bruut veel data is zou ik het gewoon storen in je ViewState.

[Luuk1983]

Grijze Vos schreef op donderdag 04 augustus 2011 @ 16:24:
Als het niet bruut veel data is zou ik het gewoon storen in je ViewState.

Dan moet je data ook serializable zijn en dat is het in dit geval niet . En los daarvan moet je de ViewState de hele tijd heen en weer sturen en verwerken, waar door je pagina groter wordt en het downloaden van de pagina langer duurt. Maar inderdaad, voor een beetje data zou het nog een optie kunnen zijn.

[R4gnax]

Luuk1983 schreef op donderdag 04 augustus 2011 @ 16:54:
[...]

Dan moet je data ook serializable zijn en dat is het in dit geval niet . En los daarvan moet je de ViewState de hele tijd heen en weer sturen en verwerken, waar door je pagina groter wordt en het downloaden van de pagina langer duurt. Maar inderdaad, voor een beetje data zou het nog een optie kunnen zijn.

Wat voor formulier data ben je eigenlijk aan het opslaan dat deze niet serializable zou zijn? Klinkt een beetje als een ontwerpfout. Je zou eigenlijk alleen model (of viewmodel) klassen moeten gebruiken i.c.m. je formulier. Deze zijn eigenlijk altijd goed serializable te maken.

[PdeBie]

het formulier is een order formulier bestaande uit 1 lang formulier zonder gebruik te maken van een wizard o.i.d.
met verschillende modi (afhankelijk van het type order, wat ook weer on-the-fly tijdens het invoeren van een order te wijzigen is).

Binnen dit formulier heb je een aantal objecten:
- order
- verzender
- ontvanger
- uitvoerende partij
- artikelen

De order wordt gevuld met de items die er onder staan. Deze items moet ik ergens tijdelijk opslaan, alvorens ik de daadwerkelijke order opsla in de database. Er is destijds gekozen om dit in de sessie te doen.
Wordt de modus van het formulier aangepast (oftewel het type order), veranderen er een aantal velden, validaties etc. van het formulier. Dit heeft verder geen invloed op de objecten in de sessie. Deze blijven dezelfde structuur behouden. De inhoud wijzigt wel enigzins.

Alle objecten bij elkaar, praat je misschien over 10~15kb. Stelt opzich niet zoveel voor, echter gaan er ruim 1200 gebruikers dagelijks tegelijk gebruik maken van het systeem.

---

Ik heb even gekeken naar mijn huidige instellingen n.a.v. de post van Luuk1983 (duidelijke uitleg zo Luuk!) en daar moeten alle instellingen straks (op productie) op 10 uur komen te staan.
Voor de test hebben we dit nu op 1 uur ingesteld. Onze tester is dit nu aan het testen.

De eerder geposte methode (gisteren om 12:10) werkt lokaal naar behoren maar niet op de server.

[R4gnax]

pdebie schreef op vrijdag 05 augustus 2011 @ 09:43:
De order wordt gevuld met de items die er onder staan. Deze items moet ik ergens tijdelijk opslaan, alvorens ik de daadwerkelijke order opsla in de database. Er is destijds gekozen om dit in de sessie te doen.
Wordt de modus van het formulier aangepast (oftewel het type order), veranderen er een aantal velden, validaties etc. van het formulier. Dit heeft verder geen invloed op de objecten in de sessie. Deze blijven dezelfde structuur behouden. De inhoud wijzigt wel enigzins.

Alle objecten bij elkaar, praat je misschien over 10~15kb. Stelt opzich niet zoveel voor, echter gaan er ruim 1200 gebruikers dagelijks tegelijk gebruik maken van het systeem.

Tenzij je enorme orders gaat serializeren maakt het qua performance echt geen drol uit. Alleen al de overhead die DotNetNuke introduceert zal een fundamenteel groter effect hebben. En 10~15kB (kilobyte, en niet -bit, neem ik aan?) is echt behoorlijk klein, wat dat betreft.

Deserializeren is iets duurder, maar ook nog behoorlijk verwaarloosbaar. Als het echt bezwaarlijk is, dan kun je altijd nog proberen om een twee-traps systeem te hanteren waarbij je een in-process cache aanmaakt van je out-of-process session. Je hoeft dan enkel de sessie te deserializeren wanneer de applicatie zich zou recyclen. Daarbij geldt wel de aanname dat WebForms de sessie 'lazy' deserialiseert. (Denk trouwens dat dat niet zo is, maar je zou het kunnen proberen. Anders kun je altijd nog met de hand van/naar json serializeren en de zo één enkele string in de sessie stoppen.)

Verder zie ik niet in waarom het soort objecten dat je hier beschrijft niet serializable zou zijn. Voor dit soort zaken heb je nou net een scheiding tussen data access objects (DAOs) en data transfer objects (DTOs), oftwel: database entities enerzijds en (view)models anderzijds. Het enige wat ik me kan bedenken is dan ook dat de applicatie zo dom in elkaar zit dat er direct van niet te serializeren database entities gebruik gemaakt wordt.

[ Voor 9% gewijzigd door R4gnax op 05-08-2011 12:20 ]