[ASP.net / C#] - Sessie in leven houden

[Verwijderd]

M.b.v. javascript loopt er een timer af als de session dreigt te verdwijnen. Er wordt dan een popupvenster getoond met een ja en een nee knop (een nieuwe asp-pagina). Als er op Ja wordt geklikt, moet de sessie-timeout weer op maximaal gezet worden. Gaat dit direct goed doordat een postback wordt getriggerd doordat er op Ja wordt geklikt? Of moet ik alle variabelen ophalen uit de sessie en er weer opnieuw inzetten op bv de volgende manier:

C:

foreach (string s in Session) 
{
    Session[s] = Session[s];
}

Ziet er nogal kansloos uit... Ik heb genoeg gegoogled en ik kon hier niets over vinden.

Dit topic had ik al gevonden trouwens: [rml][ ASP] Session oneindig lang, of gebruiker waarschuwen?[/rml]

[whoami]

Waarom zet je niet gewoon de sessie-timeout in je web-config naar een hogere waarde ?

[gorgi_19]

Zet de session Timeout op 22 minuten en laat de waarschuwing na 20 minuten naar voren komen oid.

[Verwijderd]

whoami schreef op donderdag 29 september 2005 @ 10:01:
Waarom zet je niet gewoon de sessie-timeout in je web-config naar een hogere waarde ?

Ja, dat kan ook wel, maar dan heb je in theorie nog steeds hetzelfde probleem. Er dienen gegevens aangepast te worden en stel dat de gebruiker twee uur wegloopt of weet ik veel wat, dan mogen die gegevens eigenlijk niet verloren gaan.

Het was een idee van mijn stagebegeleider en ik zou het mooi vinden als het ook gaat werken, is weer goed voor mijn eindcijfer .

[Verwijderd]

zoiets:

http://www.codeproject.com/aspnet/Session_Defibrillator.asp

[Verwijderd]

gorgi_19 schreef op donderdag 29 september 2005 @ 10:03:
Zet de session Timeout op 22 minuten en laat de waarschuwing na 20 minuten naar voren komen oid.

Ja, dat heb ik dus al. Maar ik weet dus niet precies hoe ik dan de sessie weer moet 'verlengen'. Gaat dit puur goed door de postback die wordt getriggerd door de buttonclick?

[whoami]

Verwijderd schreef op donderdag 29 september 2005 @ 10:00:
Gaat dit direct goed doordat een postback wordt getriggerd doordat er op Ja wordt geklikt? Of moet ik alle variabelen ophalen uit de sessie en er weer opnieuw inzetten op bv de volgende manier:

Eh, de werking van de sessie staat toch ook uitgelegd in de MSDN ?
Vanzodra de user een actie doet, en die actie wordt 'opgemerkt', dan wordt de sessie-timeout toch gereset ?

[CodeCaster]

Google: when does asp session timeout

When does a Session End?
A session ends if a user has not requested or refreshed a page in the application for a specified period. By default, this is 20 minutes.

Dus... wss wordt door enkel je javascript pop-up alweer 20 minuten opgeteld ;-)

Kun je niet als test de sessie op 1 minuut zetten, een sessievariabele vullen en na 50 seconden een javascript popup tonen met die sessievariabele erin?

[gorgi_19]

Verwijderd schreef op donderdag 29 september 2005 @ 10:05:
[...]

Ja, dat heb ik dus al. Maar ik weet dus niet precies hoe ik dan de sessie weer moet 'verlengen'. Gaat dit puur goed door de postback die wordt getriggerd door de buttonclick?

Postback genereren; anders kan je ws ook wel met Javascript een timer oid maken en aan het einde een callback naar de server doen, zonder dat de gebruiker er iets van merkt.

[Verwijderd]

gorgi_19 schreef op donderdag 29 september 2005 @ 10:10:
[...]

Postback genereren; anders kan je ws ook wel met Javascript een timer oid maken en aan het einde een callback naar de server doen, zonder dat de gebruiker er iets van merkt.

Ik zal die defibrillator even proberen

CodeCaster schreef op donderdag 29 september 2005 @ 10:09:
Google: when does asp session timeout


[...]


Dus... wss wordt door enkel je javascript pop-up alweer 20 minuten opgeteld ;-)

Kun je niet als test de sessie op 1 minuut zetten, een sessievariabele vullen en na 50 seconden een javascript popup tonen met die sessievariabele erin?

Zal ik even testen

[ Voor 39% gewijzigd door Verwijderd op 29-09-2005 10:27 ]

[Verwijderd]

posts samengevoegd kan deze wel weg

[ Voor 224% gewijzigd door Verwijderd op 29-09-2005 10:28 ]

[whoami]

Test dan ook even de edit-knop aub.

[Verwijderd]

Ik heb het getest. Timeout op 1 minuut, na 50 sec wordt een popup getoond. Als ik dan na 20 seconden een sessievar opvraag, bestaat deze nog. Dus het werkt zoals ik eigenlijk ook had verwacht .

[Woy]

Je zou ook iets kunnen doen met het Session_End event. Als je op dat moment de session wegschrijft naar b.v. een db dan kan je bij het opnieuw opstarten van een session kijken of er nog oude data beschikbaar is en de gebruiker vragen of hij die wil gebruiken.

[gorgi_19]

CodeCaster schreef op donderdag 29 september 2005 @ 10:09:
Dus... wss wordt door enkel je javascript pop-up alweer 20 minuten opgeteld ;-)

Kun je niet als test de sessie op 1 minuut zetten, een sessievariabele vullen en na 50 seconden een javascript popup tonen met die sessievariabele erin?

Nee, het gaat om een connectie naar de server, niet om clientside connectiviteit c.q. acties.

[Woy]

gorgi_19 schreef op donderdag 29 september 2005 @ 10:59:
[...]

Nee, het gaat om een connectie naar de server, niet om clientside connectiviteit c.q. acties.

Ok maar als je javascript pop-up weer een page laad dan wordt je sessie wel weer verlengd

[gorgi_19]

rwb schreef op donderdag 29 september 2005 @ 11:00:
[...]

Ok maar als je javascript pop-up weer een page laad dan wordt je sessie wel weer verlengd

Dan is het niet alleen een clientside actie meer, maar zit er ook een connectie naar de server bij

[Woy]

gorgi_19 schreef op donderdag 29 september 2005 @ 11:06:
[...]

Dan is het niet alleen een clientside actie meer, maar zit er ook een connectie naar de server bij

ja idd, maar dat was denk ook wat CodeCaster bedoelde

[CodeCaster]

Inderdaad ;-)

Blij dat het opgelost is.

[Verwijderd]

Denk hierbij ook na over de schaalbaarheid en controle van dit soort oplossingen. Voor iedere sessie die openstaat worden er server resources gebruikt. Als er heel veel gebruikers zomaar een browser open laten staan op die site, kan dat leiden tot een behoorlijke belasting.

Je hoeft geen gegevens te verliezen op het ogenblik dat je sessie timeed-out is. Als je na je postback erachter komt dat er bijvoorbeeld geen oude sessie is waarbinnen de user authenticated is, kan je de gegevens uit het inputform alsnog in de nieuwe sessie opslaan, de user opnieuw laten inloggen, om vervolgens te redirecten naar het oude form en alle waardes weer in het formulier te zetten. Ook zijn er manieren om een gegevens uit een sessie in een database vast te leggen, zodat die weer aan de nieuwe sessie gekoppeld kan worden.

Ja, dit is een meer complexe dan bijvoorbeeld de oplossing in de link van iruoy, maar voor situaties waarin schaalbaarheid nodig is, een veel beter bruikbare oplossing. Kies de juiste oplossing voor de juiste situatie en ken de beperkingen ervan.

[Verwijderd]

Het aantal gebruikers is niet zo hoog, totaal maximaal 30 en die zijn nooit tegelijkertijd ingelogd. Schaalbaarheid is dus geen probleem...

[CodeCaster]

Sowieso lijken server resources mij niet zo'n "hot item" qua schaalbaarheid;

Stel, 10.000 gebruikers zijn ingelogd en het enige wat je in sessievariabelen opslaat is het GebruikersID, dan ben je daaraan nog geen 40 KB geheugen kwijt...

Correct me if I'm wrong!

Uiteraard kan de hoeveelheid gegevens aardig oplopen naarmate je meer opslaat per gebruiker, maar voor 30 gebruikers zou ik niet al te moeilijk doen.

[Woy]

Verwijderd schreef op donderdag 29 september 2005 @ 12:14:
Het aantal gebruikers is niet zo hoog, totaal maximaal 30 en die zijn nooit tegelijkertijd ingelogd. Schaalbaarheid is dus geen probleem...

Nu niet maar dat is juist het leuke aan schaalbaarheid dat het pas later nodig kan zijn. Dan zou je dus alles om moeten bouwen.

Wat voor data moet je precies bewaren. Het zou mij toch handiger lijken om de balangrijke data die in je session staat automatisch op te slaan op het moment dat je sesion verloopt. Bij het opnieuw opstarten van een session kan je dan kijken of de gebruiker nog oude data heeft staan en dan eventueel vragen of hij die wil gebruiken. Je raakt in dit geval geen data kwijt en je bent ook niet aan het kloten om je session zo lang mogenlijk open te houden.

[Verwijderd]

Er wordt wel veel opgeslagen... Een paar variabelen als gebruikersnaam, type user e.d., maar ook een dataset waar een table in staat met +- 15 kolommen en +- 100-400 rijen.

Ik zal er eens over nadenken!

rwb schreef op donderdag 29 september 2005 @ 12:29:
[...]

Nu niet maar dat is juist het leuke aan schaalbaarheid dat het pas later nodig kan zijn. Dan zou je dus alles om moeten bouwen.

Wat voor data moet je precies bewaren. Het zou mij toch handiger lijken om de balangrijke data die in je session staat automatisch op te slaan op het moment dat je sesion verloopt. Bij het opnieuw opstarten van een session kan je dan kijken of de gebruiker nog oude data heeft staan en dan eventueel vragen of hij die wil gebruiken. Je raakt in dit geval geen data kwijt en je bent ook niet aan het kloten om je session zo lang mogenlijk open te houden.

[Woy]

Verwijderd schreef op donderdag 29 september 2005 @ 12:34:
Er wordt wel veel opgeslagen... Een paar variabelen als gebruikersnaam, type user e.d., maar ook een dataset waar een table in staat met +- 15 kolommen en +- 100-400 rijen.

Kan je die dataset niet opnieuw opbouwen op het moment dat hij weer opnieuw opgevraagd wordt? Of zijn er ook wijzigingen in aangebracht. Maar als het geen probleem is dat het in het geheugen ( Session ) wordt gehouden lijkt het me al helemaal geen probleem om het in een database weg te schrijven. Een database cached het mischien tijdelijk in het geheugen maar uiteindelijk staat het gewoon op de hd. Tevens haalt het dan voor de gebruiker ook niet uit of de server ( of zelfs alleen het aspnet process ) opnieuw opgestart wordt nadat zijn session is verlopen.

[Verwijderd]

Een database query is nogal heavy, aangezien het via een scriptserver van een boekhoudprogramma (AccountView) gaat... Dus liever niet teveel database queries. Tevens kan ik daar ook geen data in opslaan in een tijdelijke tabel oid, dus op die manier gaat het niet werken.

rwb schreef op donderdag 29 september 2005 @ 12:55:
[...]

Kan je die dataset niet opnieuw opbouwen op het moment dat hij weer opnieuw opgevraagd wordt? Of zijn er ook wijzigingen in aangebracht. Maar als het geen probleem is dat het in het geheugen ( Session ) wordt gehouden lijkt het me al helemaal geen probleem om het in een database weg te schrijven. Een database cached het mischien tijdelijk in het geheugen maar uiteindelijk staat het gewoon op de hd. Tevens haalt het dan voor de gebruiker ook niet uit of de server ( of zelfs alleen het aspnet process ) opnieuw opgestart wordt nadat zijn session is verlopen.

[Woy]

Verwijderd schreef op donderdag 29 september 2005 @ 12:59:
Een database query is nogal heavy, aangezien het via een scriptserver van een boekhoudprogramma (AccountView) gaat... Dus liever niet teveel database queries. Tevens kan ik daar ook geen data in opslaan in een tijdelijke tabel oid, dus op die manier gaat het niet werken.
[...]

Het hoeft ook niet in een tijdelijke tabel. Je zou er een vaste tabel van kunnen maken. Accountview werkt zover ik weet met Foxpro toch? Je zou er ook voor kunnen kiezen om het per user naar een bestandje op de hard disk te schrijven.

[Verwijderd]

rwb schreef op donderdag 29 september 2005 @ 13:58:
[...]

Het hoeft ook niet in een tijdelijke tabel. Je zou er een vaste tabel van kunnen maken. Accountview werkt zover ik weet met Foxpro toch? Je zou er ook voor kunnen kiezen om het per user naar een bestandje op de hard disk te schrijven.

Ja, maar ik gebruik de XML-scripts, geen Foxpro-scripts dus.

Ik heb niet de rechten om tables toe te voegen, ik weet ook niet of ze dat willen. Ik zal het aan mijn stagebegeleider voor leggen.

[Woy]

Verwijderd schreef op donderdag 29 september 2005 @ 14:25:
[...]

Ja, maar ik gebruik de XML-scripts, geen Foxpro-scripts dus.

Ik heb niet de rechten om tables toe te voegen, ik weet ook niet of ze dat willen. Ik zal het aan mijn stagebegeleider voor leggen.

Ik weet niet precies over wat voor data het gaat maar ik kan me idd voorstellen dat je dat niet altijd in je AccountView database wilt hebben.

Als ik jou was zou ik zeker de optie om je DataSet opnieuw op te halen uit je database overwegen. Zo zwaar zijn queries nou ook weer niet en het duurt vrij lang voordat een Session verloopt. Dus dan lijkt het me niet extreem zwaar om de querie nogmaals te draaien.

En gegevens over de gebruiker kun je ook gewoon opnieuw ophalen lijkt me. Je gebruiker zal toch op een of andere manier opnieuw in moeten loggen ( Dit hoeft natuurlijk niet perse met interactie van de gebruiker maar kan ook door middel van een AuthenticationTicket of Windows authentication ) en dan kan je gewoon alle gegevens die je nodig hebt weer opnieuw ophalen zonder dat de gebruiker daar wat van merkt.