[ASP.NET] Database in session?

[Jabbah]

Ik heb een webapplicatie met meerdere aspx pagina's, waarbij ik in elke pagina de database aanspreek (records uitlezen, updaten of deleten).
Ik heb een Database object gemaakt dat de database beheert. Deze klasse heeft dus methodes zoals LeesTabel, UpdateTabel etc.. Eigenlijk een soort library die ik ook voor andere webapplicaties kan gaan gebruiken.

Wat ik momenteel toe is bij het starten van de webapplicatie, de database in mijn Database object laden en vervolgens dit object in de Session opslaan, zodat ik de Session (en dus de database) in andere pagina's weer kan uitlezen.

1. Is deze methode van het opslaan van het Database object in de Session een goed idee?
2. Neemt het Database object (dat de DataSet bevat) niet heel veel geheugen in beslag bij hele grote databases, of maakt dat niet uit? M.a.w. wordt de database zelf in het geheugen geladen of bevat het DataSet object slechts 'referenties' naar de fysieke database?

[gorgi_19]

Hoe is de content gebonden? User gebonden? Hoe groot is de frequentie van bekijken? * gorgi_19 gokt dat Outputcache meer profijt heeft...

[ Voor 226% gewijzigd door gorgi_19 op 31-03-2004 12:45 ]

[MeIsTwisted]

edit verkeerd gelezen

[ Voor 88% gewijzigd door MeIsTwisted op 31-03-2004 12:43 ]

[whoami]

Jabbah schreef op 31 maart 2004 @ 12:40:
Ik heb een webapplicatie met meerdere aspx pagina's, waarbij ik in elke pagina de database aanspreek (records uitlezen, updaten of deleten).
Ik heb een Database object gemaakt dat de database beheert. Deze klasse heeft dus methodes zoals LeesTabel, UpdateTabel etc.. Eigenlijk een soort library die ik ook voor andere webapplicaties kan gaan gebruiken.

Wat ik momenteel toe is bij het starten van de webapplicatie, de database in mijn Database object laden en vervolgens dit object in de Session opslaan, zodat ik de Session (en dus de database) in andere pagina's weer kan uitlezen.

1. Is deze methode van het opslaan van het Database object in de Session een goed idee?
2. Neemt het Database object (dat de DataSet bevat) niet heel veel geheugen in beslag bij hele grote databases, of maakt dat niet uit? M.a.w. wordt de database zelf in het geheugen geladen of bevat het DataSet object slechts 'referenties' naar de fysieke database?

De DataSet bevat gegevens, en die gegevens nemen geheugen in beslag. Ik denk niet dat het wenselijk is -zeker als je veel users hebt die tegelijk op de DB zitten- die hele hoop data altijd in het geheugen te houden op de server.
Daarnaast is het ook niet wenselijk om zo te werken, aangezien je dan niet zeker bent of je wel met recente data zit te werken. De data die jij in je dataset hebt, kan al verouderd zijn tov de data in de databank.

[DanTm]

Jabbah schreef op 31 maart 2004 @ 12:40:
Ik heb een webapplicatie met meerdere aspx pagina's, waarbij ik in elke pagina de database aanspreek (records uitlezen, updaten of deleten).
Ik heb een Database object gemaakt dat de database beheert. Deze klasse heeft dus methodes zoals LeesTabel, UpdateTabel etc.. Eigenlijk een soort library die ik ook voor andere webapplicaties kan gaan gebruiken.

Wat ik momenteel toe is bij het starten van de webapplicatie, de database in mijn Database object laden en vervolgens dit object in de Session opslaan, zodat ik de Session (en dus de database) in andere pagina's weer kan uitlezen.

1. Is deze methode van het opslaan van het Database object in de Session een goed idee?
2. Neemt het Database object (dat de DataSet bevat) niet heel veel geheugen in beslag bij hele grote databases, of maakt dat niet uit? M.a.w. wordt de database zelf in het geheugen geladen of bevat het DataSet object slechts 'referenties' naar de fysieke database?

microsoft raad zelf aan om zo min mogelijk (liefst geen) objecten in een session te plaatsen (i.v.m. resources), laat staan open database connecties (dat zorgt erg snel voor connection starvation op de database)...
ik zou het database object gewoon aanmaken bij elke aanroep van je pagina, of wanneer je het nodig hebt..

[whoami]

DanTm schreef op 31 maart 2004 @ 13:17:
[...]


microsoft raad zelf aan om zo min mogelijk (liefst geen) objecten in een session te plaatsen (i.v.m. resources)

Hoe dan? In .NET is alles eigenlijk een object.

[DanTm]

whoami schreef op 31 maart 2004 @ 13:22:
[...]

Hoe dan? In .NET is alles eigenlijk een object.

ik zei ook niet dat je geen objecten mag gebruiken... maar plaats ze gewoon niet in een session.. zonde van de resources. Tenzij je zeker weet dat je webapplicatie nooit enige load van betekenis krijgt.

[gorgi_19]

DanTm schreef op 31 maart 2004 @ 13:24:
[...]


ik zei ook niet dat je geen objecten mag gebruiken... maar plaats ze gewoon niet in een session.. zonde van de resources. Tenzij je zeker weet dat je webapplicatie nooit enige load van betekenis krijgt.

Er is niets mis mee om objecten in sessions te plaatsen... Ze vreten alleen wel wat geheugen... Als je die zaken te pas en te onpas er in zet, gaat het fout.

Wat whoami verder bedoeld is dat een string ook een object is.

[ Voor 7% gewijzigd door gorgi_19 op 31-03-2004 13:29 ]

[Jabbah]

microsoft raad zelf aan om zo min mogelijk (liefst geen) objecten in een session te plaatsen (i.v.m. resources), laat staan open database connecties (dat zorgt erg snel voor connection starvation op de database)...
ik zou het database object gewoon aanmaken bij elke aanroep van je pagina, of wanneer je het nodig hebt..

Deze aanpak heb ik ook bekeken. Ik loop dan tegen het volgende probleem aan:
Stel ik heb een pagina dat een aantal contactpersonen weergeeft. De contactpersonen haal ik uit een DataSet. Als ik een contactpersoon aanklik kom ik op een andere pagina, waar ik de persoonsgegevens kan veranderen (het contactpersoon object geef ik wel mee in de Session). Als ik de wijzigingen wil terugschrijven naar de database, heb ik een probleem: Mijn DataSet kan ik namelijk niet meer bij (tenzij ik 'm meegeef in de Session, maar dat wil ik zeker niet meer doen).

Ik kan natuurlijk wel opnieuw een connectie maken met de database en de gegevens wegschrijven dmv een sql command. Dit heeft als nadeel de extra database connectie (langzamer). Ten tweede zou ik liever de originele DataSet gebruiken en dan een simpele DataAdapter.Update() uitvoeren.

Dit lijkt me echter de enige nette oplossing, of is het toch op de andere manier mogelijk (via de DataSet)?

[ Voor 4% gewijzigd door Jabbah op 31-03-2004 13:38 ]

[gorgi_19]

Hoe traag (of hoe snel) denk je dat een databaseconnectie is? Je hebt als het goed is connectionpooling, zodat het aanmaken van een connectie niet 'duur' is. En een query uitvoeren is ook niet zo een zware bevalling.

Ik voer zelf ook tig queries af en toe uit per pagina en nog geen klachten gehad over de snelheid, iig..

[ Voor 79% gewijzigd door gorgi_19 op 31-03-2004 13:39 ]

[Jabbah]

gorgi_19 schreef op 31 maart 2004 @ 13:37:
Hoe traag (of hoe snel) denk je dat een databaseconnectie is?

In ieder geval trager dan een object benaderen in het geheugen. FYI, de database staat op een aparte database server.

[gorgi_19]

Jabbah schreef op 31 maart 2004 @ 13:39:
[...]


In ieder geval trager dan een object benaderen in het geheugen. FYI, de database staat op een aparte database server.

't is trager, maar ik vind hem nu weer niet zo traag dat het opvalt, om eerlijk te zijn. Ik denk dat er met gemak andere bottlenecks in je applicatie te vinden zijn.

En een aparte database server lijkt me ook geen probleem? Kan zelfs beter werken dan de database op de webserver.

[ Voor 14% gewijzigd door gorgi_19 op 31-03-2004 13:42 ]

[DanTm]

Jabbah schreef op 31 maart 2004 @ 13:37:
[...]


Deze aanpak heb ik ook bekeken. Ik loop dan tegen het volgende probleem aan:
Stel ik heb een pagina dat een aantal contactpersonen weergeeft. De contactpersonen haal ik uit een DataSet. Als ik een contactpersoon aanklik kom ik op een andere pagina, waar ik de persoonsgegevens kan veranderen (het contactpersoon object geef ik wel mee in de Session). Als ik de wijzigingen wil terugschrijven naar de database, heb ik een probleem: Mijn DataSet kan ik namelijk niet meer bij (tenzij ik 'm meegeef in de Session, maar dat wil ik zeker niet meer doen).

Ik kan natuurlijk wel opnieuw een connectie maken met de database en de gegevens wegschrijven dmv een sql command. Dit heeft als nadeel de extra database connectie (langzamer). Ten tweede zou ik liever de originele DataSet gebruiken en dan een simpele DataAdapter.Update() uitvoeren.

Dit lijkt me echter de enige nette oplossing, of is het toch op de andere manier mogelijk (via de DataSet)?

in de overzichts pagina gebruik je gewoon een dataset om de personen te laten zien, als je er eentje aanklik geef je alleen het id van deze persoon mee aan de andere pagina. In deze pagina haal je die ene persoon op via een dataset (in de onload), als je dan de pagina submit update je de dataset (die inmiddels weer opnieuw opgehaald is) en doet dan een update v/d dataset. Hier zijn natuurlijk talloze varianten op te bedenken. Maar wat van belang is dat je tussen page executions geen gegevens vasthoud (het zogenaamde stateless principe). Alle gegevens die je nodig hebt in de page zelf stoppen (via de querystring of form), of in de db opslaan.
Nogmaals, als je verwacht een lage load te krijgen kun je natuurlijk met de session gaan werken.. maar mocht je in de toekomst dan toch willen schalen krijg je zeker een probleem... en jezelf goede programmeer technieken aanleren is natuurlijk altijd handig

[DanTm]

gorgi_19 schreef op 31 maart 2004 @ 13:41:
[...]

't is trager, maar ik vind hem nu weer niet zo traag dat het opvalt, om eerlijk te zijn. Ik denk dat er met gemak andere bottlenecks in je applicatie te vinden zijn.

En een aparte database server lijkt me ook geen probleem? Kan zelfs beter werken dan de database op de webserver.

ik sluit mij hierbij aan... de performance kost om gegevens op te halen bij een webapplicatie is niet tevergelijken met de impact van het vasthouden van gegevens in het geheugen (session) bij een zware load.
Het opvragen van gegevens kost maar een klein beetje tijd, geheugen vast houden is voortdurend (een session is vaak minimaal 20 minuten, waarvan je effectief mischien maar 1 seconde processor tijd benut, die overige tijd word het geheugen alleen maar onnodig belast)

[whoami]

DanTm schreef op 31 maart 2004 @ 13:44:
[...]


in de overzichts pagina gebruik je gewoon een dataset om de personen te laten zien, als je er eentje aanklik geef je alleen het id van deze persoon mee aan de andere pagina. In deze pagina haal je die ene persoon op via een dataset (in de onload), als je dan de pagina submit update je de dataset (die inmiddels weer opnieuw opgehaald is) en doet dan een update v/d dataset. Hier zijn natuurlijk talloze varianten op te bedenken. Maar wat van belang is dat je tussen page executions geen gegevens vasthoud (het zogenaamde stateless principe). Alle gegevens die je nodig hebt in de page zelf stoppen (via de querystring of form), of in de db opslaan.

Zo zou ik het idd ook doen, maar om nu te stellen dat je niets in je Session mag stoppen, vind ik ook weer overdreven.
(Een hele DB of tabel in je sessie houden per user, is nu natuurlijk ook weer overdreven/van het goede teveel).

Nogmaals, als je verwacht een lage load te krijgen kun je natuurlijk met de session gaan werken.. maar mocht je in de toekomst dan toch willen schalen krijg je zeker een probleem... en jezelf goede programmeer technieken aanleren is natuurlijk altijd handig

Je kan je sessie-variable altijd zelf 'clearen', een een beetje web-server heeft wel geheugen genoeg om een paar objecten per user in memory te houden hoor.
Daarnaast bestaat er ook nog altijd zoiets als 'swappen'.

[ Voor 4% gewijzigd door whoami op 31-03-2004 14:13 ]

[Jabbah]

Dank allen voor de reacties/suggesties! Ik ben een stuk wijzer geworden.

[Matthijs Hoekstra]

DanTm schreef op 31 maart 2004 @ 13:44:
[...]


in de overzichts pagina gebruik je gewoon een dataset om de personen te laten zien, als je er eentje aanklik geef je alleen het id van deze persoon mee aan de andere pagina. In deze pagina haal je die ene persoon op via een dataset (in de onload), als je dan de pagina submit update je de dataset (die inmiddels weer opnieuw opgehaald is) en doet dan een update v/d dataset. Hier zijn natuurlijk talloze varianten op te bedenken. Maar wat van belang is dat je tussen page executions geen gegevens vasthoud (het zogenaamde stateless principe). Alle gegevens die je nodig hebt in de page zelf stoppen (via de querystring of form), of in de db opslaan.
Nogmaals, als je verwacht een lage load te krijgen kun je natuurlijk met de session gaan werken.. maar mocht je in de toekomst dan toch willen schalen krijg je zeker een probleem... en jezelf goede programmeer technieken aanleren is natuurlijk altijd handig

Dit is exact de manier hoe je het moet doen, ga nooit databases resources lang opslaan in sessions etc. Dit is een echte klasieke fout.
Database connectie opzetten is inderdaad zo gebeurd door de connection pooling.

Als het nu om een app gaat met 2 gebruikers ala, maar tis geen best practice

[whoami]

BigM321 schreef op 31 maart 2004 @ 15:40:
[...]

Dit is exact de manier hoe je het moet doen, ga nooit databases resources lang opslaan in sessions etc. Dit is een echte klasieke fout.

Wat versta je onder 'database resources' ?
Een connectie moet je idd niet in een sessie houden; die moet je nl. sluiten van zodra je ze niet meer nodig hebt.
Echter, versta jij onder een 'database resource' ook een custom object die gegevens bevat vanuit de DB, of een datatable met een klein aantal rows ?

[Matthijs Hoekstra]

whoami schreef op 31 maart 2004 @ 15:42:
[...]

Wat versta je onder 'database resources' ?
Een connectie moet je idd niet in een sessie houden; die moet je nl. sluiten van zodra je ze niet meer nodig hebt.
Echter, versta jij onder een 'database resource' ook een custom object die gegevens bevat vanuit de DB, of een datatable met een klein aantal rows ?

Ik bedoel inderdaad databaseconnecties en complete datatables.

Laatst nog gezien, een klant die datatables in sessions bewaard en daar op filters en dataviews plaatst. SQL is daar veel beter in en bleek ook dat deze 'optimalisatie' juist de performance nadelig beinvloedde.

[Verwijderd]

Jabbah schreef op 31 maart 2004 @ 14:15:
Dank allen voor de reacties/suggesties! Ik ben een stuk wijzer geworden.

Misschien dat ik nog een goede suggestie voor je heb. Er bestaat zoiets als O/R Mapper. Deze maakt van de database allemaal classes. Als je nou vervolgens al deze classes even compileert naar een dll, kun je met gemak alle functionaliteit oproepen en runtime updaten/inserten/deleten whatever...

edit:
Tip weggehaald, stond stom

[ Voor 5% gewijzigd door Verwijderd op 22-04-2004 14:14 ]

[gorgi_19]

Verwijderd schreef op 01 april 2004 @ 19:55:
[...]

Misschien dat ik nog een goede suggestie voor je heb. Er bestaat zoiets als O/R Mapper. Deze maakt van de database allemaal classes. Als je nou vervolgens al deze classes even compileert naar een dll, kun je met gemak alle functionaliteit oproepen en runtime updaten/inserten/deleten whatever...

Tip: www.raptier.com

D'r zijn nog meer O/R mappers dan alleen raptier, zoals EntitityBroker of LLBLGen Pro. Paul Wilson heeft verder ook nog een eigen O/R mapper gemaakt, maar hier is wat kritiek op geweest en is ook nooit beschouwd als een commercieel en volledig product.

Alleen een O/R mapper staat los van het feit of je bepaalde data moet cachen (voor snellere toegankelijkheid) in een session, cache of niet.

[Verwijderd]

Ik plijt toch wel voor Raptier, vanwege zijn freeware versie (echter niet meer 15 tables & 15 views mogelijk -> bij shareware wel meer). Verder ook vanwege zeer goede ondersteuning en het makkelijk toevoegen extra functies via de active templates. Gebruik het nu al meer dan een maand en nog geen nadelen ondervonden...

Maar dat staat inderdaad los van het feit of je data wil cachen of niet. Het hangt een beetje af van hoe druk het gaat worden op een website. Over het algemeen moet het met een beetje goede server geen probleem zijn een paar objecten per user weg te schrijven, kan ie makkelijk aan...

[EfBe]

Jabbah schreef op 31 maart 2004 @ 12:40:
Ik heb een webapplicatie met meerdere aspx pagina's, waarbij ik in elke pagina de database aanspreek (records uitlezen, updaten of deleten).
Ik heb een Database object gemaakt dat de database beheert. Deze klasse heeft dus methodes zoals LeesTabel, UpdateTabel etc.. Eigenlijk een soort library die ik ook voor andere webapplicaties kan gaan gebruiken.

Wat ik momenteel toe is bij het starten van de webapplicatie, de database in mijn Database object laden en vervolgens dit object in de Session opslaan, zodat ik de Session (en dus de database) in andere pagina's weer kan uitlezen.

1. Is deze methode van het opslaan van het Database object in de Session een goed idee?

Nee. Bij 1000 gebruikers heb jij 1000 keer die database in memory . Daarnaast loop je tegen dingen aan als: hoe houd ik alles in sync (memory/db), hoe query ik de boel?

2. Neemt het Database object (dat de DataSet bevat) niet heel veel geheugen in beslag bij hele grote databases, of maakt dat niet uit? M.a.w. wordt de database zelf in het geheugen geladen of bevat het DataSet object slechts 'referenties' naar de fysieke database?

DataSets bevatten datatable objects, die 2 dingen bevatten: datacolumn definities (1 per column) en datarows (1 per row). Datarows bevatten per column een cell met daarin een reference naar het dataelement in die cell. De data is wel fysiek in memory aanwezig. Dus als jij 1000 rows laadt in een dataset, heb je die data in memory staan. Er is geen verbinding met de database aanwezig.

Wat je t.a.t. moet zien te voorkomen is dat je veel data in memory houdt. Dit levert nl. problemen op wanneer je in thread A (die bij bezoeker A hoort) iets met de data wilt doen en in thread B (die bij bezoeker B hoort) je die data al hebt geupdate, in de database. Een cache lijkt dan leuk, maar omdat ASP.NET appdomains recycled, loop je het risico dat thread A een andere cache ziet dan thread B.

Wat je dus moet doen is zoveel mogelijk op de db werken: haal de data op die je nodig hebt voor een bepaalde actie: pagina opbouwen bv. Wanneer je data wilt wegschrijven, bv een nieuw record, dan schrijf je het dan weg en als je data nodig hebt voor dat wegschrijven, haal je dat DAN op.

Verder moet je je voor performance richten op het cachen van processed data, dus blokjes html die je in je pagina opneemt, bv de output van een user control. Gebruik hiervoor de asp.net cache objects. Dit is vele malen efficienter dan datacachen, want je hoeft uberhaupt niets meer te doen en dus OOK geen processing meer te doen op de data.

Verwijderd schreef op 01 april 2004 @ 23:07:
Ik plijt toch wel voor Raptier, vanwege zijn freeware versie (echter niet meer 15 tables & 15 views mogelijk -> bij shareware wel meer). Verder ook vanwege zeer goede ondersteuning en het makkelijk toevoegen extra functies via de active templates. Gebruik het nu al meer dan een maand en nog geen nadelen ondervonden...

Blijft behelpen hoor, Raptier. Hoe wil je filteren op 'product' wanneer je alle customers wilt ophalen die een bepaald product hebben gekocht? Bij mijn weten kun je geen queries opgeven met iets simpels als relaties.

[ Voor 12% gewijzigd door EfBe op 02-04-2004 11:30 ]

[Cuball]

databank klasse op de sessie plaatsten is zoals eerder gezegd niet zo'n goede manier van werken.

voor mijn .NET applicaties gebruik ik dezelfde methode zoals ik dat deed met J2EE, namelijk een singleton patern gebruiken voor je databank klasse en dan in je codebehind gewoon dit opbject opvragen

[vinnux]

Voor zover mijn kennis gaat worden database connecties en zeker die met SQL database gepooled. Het maken van een connectie kost dus nadat er eenmaal een pool is geen extra tijd.
Daarnaast moet je een DB laten doen waar hij goed in is, gegevens aanbieden. De gegevens van jouw DataSet zullen vast nog ergens in de cache van de database zitten. Deze kan hij dus snel retouneren.

Anders moet je zelf een pool van te bewaren DataSets bouwen op applicatie niveau, en een referentie in de session stoppen. Het is even programmeren, maar dan heb je wel wat . Maar ja dan maak je weer een soort DBMS. He een cirkel

[ Voor 6% gewijzigd door vinnux op 02-04-2004 23:47 ]

[Verwijderd]

EfBe schreef op 02 april 2004 @ 11:20:
Blijft behelpen hoor, Raptier. Hoe wil je filteren op 'product' wanneer je alle customers wilt ophalen die een bepaald product hebben gekocht? Bij mijn weten kun je geen queries opgeven met iets simpels als relaties.

Eerst niet, maar met ondersteuning via het forum en eigen implementatie ben ik een heel end gekomen. Maar tis ook een kwestie van smaak (en het feit dat zij freeware hebben).