[ASP.NET C#]Connectie loopt vol

[6K]

Ik heb een acces database met 4 tabellen erin. Niets spannends dus.

Wanneer ik met mijn webapplicatie deze benader om te onderhouden (Wijzigen / Updaten / Deleten) werkt het allemaal prima, echter...

zodra ik niet 1 row edit of toevoeg, maar door mijn applicatie ga wandelen en links en rechts wat ga toevoegen en deleten zegt ie na xx keer dat er te veel gebruikers zijn en dus de pagina niet meer weer kan geven

Nu heb ik het donkerbruine vermoeden dat ik iets vergeet te doen.
Ik heb een dataclass die de connectie's en queries verzorgt en daar roep ik in iedere functie netjes de dispose() aan van de connectie.

iemand?

[whoami]

Sluit je je connectie iedere keer als je ze niet meer nodig hebt?

[6K]

ja, ik open hem, voer de query uit en sluit hem en dispose hem

en bij ophalen van tabellen voor dataset dispose ik hem ook

[whoami]

Die dispose moet je iig niet aanroepen.

[6K]

Huh? why not? die is daar toch speciaal voor?
Als ik hem niet aanroep gaat het overigens nog steeds fout

[whoami]

Dispose released alle resources van het object. Echter, als je de close aanroept van de connection, dan wordt je connection naar de connection-pool gebracht (indien dit ge-enabled is).
Volgens mij zal je toch nog ergens een connection hebben die niet gesloten wordt ofzo. Ben je zeker dat die connectie ook gesloten wordt als er een fout optreedt?
Je houdt je connectie toch niet gedurende de ganse sessie open?

[6K]

Nah, zoals ik zei heb ik een dataclass voor alle database acties.
Daarin roep ik dus mijn connectie aan als ik data nodig heb of een query wil uitvoeren. Dat is de enige plek in mijn app waar ik dat doe en daar sluit ik hem dus.

En dat is dus snel en overzichterlijk, dus ik kan er echt niet overheen kijken.
_{ik mis iets, maar ik kom er maar niet op wat...}

[EfBe]

Dispose closed ook de connectie.

Je zit waarschijnlijk op WinXP te testen. Die kan maar 10 connecties aan. Zet in de webapplicatie settings (IIS) 'Keep connections alive' UIT.

[ Voor 6% gewijzigd door EfBe op 16-04-2004 09:23 ]

[6K]

Dat meen je niet!
(ik zit hier idd op XP, maar dat moet mijn provider dan doen dus)
Super !

[6K]

De oplossing.... SINGLETON

maak van je klasse een SingleTon zodat de applicatie maar 1 instantie heeft van je connectie klasse. Hierdoor gebruiken alle clients dezelfde connectie ipv per sessie een nieuwe connectie.

Hierdoor kun je oneindig veel connecties laten lopen zonder problemen. Bovenin je code behind page kun je deze gewoon private declareren:
private DataClass MyData = DataClass.GetInstance();
(waarbij DataClass mijn klassenaam is en GetInstance even de methode is die ik snel snel gemaakt heb voor de singleton, met private constructor uiteraard)
public static DataClass GetInstance()
{
if (MyData == null)
{
MyData = new DataClass();
}
return MyData;
}

(MyData is een private static DataClass)

that's it... werkt als een tierelier... !

[EfBe]

Singleton hiervoor gebruiken is onzin. Connectionpooling zorgt voor het recycling van open connections. Indien dat bij jou niet werkt heb je, zoals al eerder gezegd, een bug in je code. Een singleton class met een open connectie is overigens funest voor performance in een asp.net applicatie. Verder is singleton niet te implementeren in asp.net, omdat je appdomain recycling hebt en dus op momenten 2 instances kunt hebben.

Maar jij stored de open connectie in de session? whoa... waarom is dat? create connection object en openen met pooling kost 12 ms of minder.

De error die je beschreef in je openingspost leek me de error van IIS waarbij je met je browser meer dan 10 connections hebt opgezet. Heeft dan dus ook niets met db's te maken.

[ Voor 12% gewijzigd door EfBe op 16-04-2004 14:53 ]

[Verwijderd]

6K schreef op 16 april 2004 @ 14:16:
De oplossing.... SINGLETON

maak van je klasse een SingleTon zodat de applicatie maar 1 instantie heeft van je connectie klasse. Hierdoor gebruiken alle clients dezelfde connectie ipv per sessie een nieuwe connectie.

Hierdoor kun je oneindig veel connecties laten lopen zonder problemen. Bovenin je code behind page kun je deze gewoon private declareren:
private DataClass MyData = DataClass.GetInstance();
(waarbij DataClass mijn klassenaam is en GetInstance even de methode is die ik snel snel gemaakt heb voor de singleton, met private constructor uiteraard)
public static DataClass GetInstance()
{
if (MyData == null)
{
MyData = new DataClass();
}
return MyData;
}

(MyData is een private static DataClass)

that's it... werkt als een tierelier... !

Euhh en wat als je meerdere threads tegelijkertijd die DataClass benaderen, dan kan het goed fout gaan, je zou eventjes naar het double checked locked pattern moeten kijken hiervoor
(link : http://www-106.ibm.com/de...s/java/library/j-dcl.html ).
Maar dan nog lijkt me dit niet echt een goede oplossing aangezien als er 2 threads vlak na elkaar dit object willen benaderen de een zal moeten wachten tot de ander klaar is en bij een lang durende query kan dat voor bepaalde gebruikers leiden tot te lange wachttijden.

Ik zou wel voor 1 DataClass instantie per session kiezen, en bij elke publieke methode in de DataClass de connectie sluiten. Verder zou je wel gebruik moeten maken van een connection pool idd aangezien dit de prestaties positief zal beinvloeden, maar ik geloof dat dit in .net automatisch gebeurd.

[whoami]

Wat als je dan gebruik gaat gaan maken van DataReaders ?
Wat als client1 z'n connectie sluit, terwijl client2 nog iets aan het doen is op de DB ?

[Verwijderd]

whoami schreef op 16 april 2004 @ 14:53:
Wat als je dan gebruik gaat gaan maken van DataReaders ?
Wat als client1 z'n connectie sluit, terwijl client2 nog iets aan het doen is op de DB ?

Je zou per methode een connectie kunnen openen en ook weer sluiten aan het eind van die methode, maar Singleton hier is gewoon een shit oplossing.

[whoami]

Verwijderd schreef op 16 april 2004 @ 14:58:
[...]


Je zou per methode een connectie kunnen openen en ook weer sluiten aan het eind van die methode, maar Singleton hier is gewoon een shit oplossing.

Dat zeg ik, als je een singleton hiervoor gebruikt, dan gaat het volgens mij toch goed in de mist gaan met concurrent connections.

[6K]

hm... klinkt alsof ik dus toch niet de goede weg in sla

connectionpooling is inderdaad automatisch (OleDb), dat gebeurt al.
Ik zet hem overigens niet in de Session, maar laat de App gewoon niet meer dan 1 instance maken.

locks, damn, dat moet ik idd wel regelen!

AppDomain Recycling ken ik helemaal niet, wat is dat?

_{toch wel balen, je zou toch verwachten dat je een tabel gerust 100 keer zou mogen editten als je je connecties netjes sluit}

[Verwijderd]

whoami schreef op 16 april 2004 @ 15:02:
[...]


Dat zeg ik, als je een singleton hiervoor gebruikt, dan gaat het volgens mij toch goed in de mist gaan met concurrent connections.

Volgens mij hoeft dat niet altijd het geval te zijn. Als je van double checked locking gebruik maakt en connection pooling en in elke publieke methode netjes de connection opend en sluit gaat het volgens mij wel goed. Dit neemt alleen niet weg dat client 2 op client 1 moet wachten als beide tegelijk een query willen uitvoeren.

[whoami]

Als je slechts 1 connectie-object gebruikt, dan zal je pool toch ook maar uit max. 1 object bestaan.

[6K]

damn... wat ben ik dom bezig zeg...

het antwoord komt zojuist voorbij. Ik moet per publieke methode mijn DataClass aanroepen, nu is dat een member van mijn form