Database connections

[whoami]

Ik zit met een dilemma.

Ik had graag eens geweten hoe jullie omgaan met database connections in desktop applications.

In Delphi ben ik gewoon om een TDatabase component te gebruiken en dmv dat TDatabase component een connectie te leggen met m'n databank die ik in het begin van m'n programma open, en pas weer sluit als mijn programma wordt afgesloten. De connectie met m'n databank blijft dus de hele tijd openstaan totdat de applicatie afgesloten wordt.

Nu ben ik bezig met C#/.net en hier was ik ook begonnen met 1 OleDbConnection of SqlConnection object te gebruiken en die connectie open te houden totdat m'n applicatie beëindigd wordt.
Nu heb ik het een en ander gelezen over connection pooling. Er wordt iedere keer een connection object aangemaakt en geopend wanneer dit nodig is, en vanzodra de query uitgevoerd wordt, wordt de connectie terug gesloten en naar een pool gestuurd. Als de applicatie dan op een later tijdstip opnieuw een connectie nodig heeft met de databank, dan kan er een connectie uit de pool gehaald worden en opnieuw geopend worden.

Nu had ik graag eens geweten hoe jullie het doen (in .Net of in Java). Wat zijn de voor- en nadelen van beide situaties?

[Verwijderd]

Connection pooling heeft imho alleen zin in 'n distributed omgeving, als je gewoon 'n 2 tier client server systeem hebt heb ik zoiets van connect 1x en hou die connectie vast..

[whoami]

Ja, ik had dezelfde mening in dit geval. Maar ik ben met deze methode wel in C# op een eigenaardigheid gestoten waar ik eigenlijk nog altijd niet uitben.
Zie ook : [topic=440251/1/25]

[Scare360]

Conn open en direct sluiten nader de transactie uitgevoerd is. Db Conn zijn aardige recource vreters en wil je absoluut niet gedurende de hele applicatie open laten. Een abstractie connectie interface definieren is wat ik doe in C#. zoiets als:

Conn.Exc("SELECT * FROM TUser") zal effectief de database conn maken... SQL uitvoeren op de SQLAdapter en een dataset retouneren. Hierna wordt direct de connectie binnen dezelfde methoden gesloten. Indien ik in een gedistribueerde omgeving meerdere client dezelfde zaken uit laat voeren is mijn C# omgeving zo slim om de zaak te poolen. In C# unleashed staat het allemaal nog eens lekker in uitgewerkt een aanrader dus om eens te lezen

[Verwijderd]

Geen idee waar ik moet reply'en nu hier dan maar, voert ie soms default z'n query's async uit ofzo? (gokker de gok)

[whoami]

Op dinsdag 19 maart 2002 14:32 schreef paulgielens het volgende:
Conn open en direct sluiten nader de transactie uitgevoerd is. Db Conn zijn aardige recource vreters en wil je absoluut niet gedurende de hele applicatie open laten. Een abstractie connectie interface definieren is wat ik doe in C#. zoiets als:

Een connectie die open staat vreet resources, ok. Maar als dat maar 1 connectie is die open staat gedurende het programma is dat toch zo erg niet? Zeker als de applicatie redelijk databank-intensief is.
Het openen van connecties zal toch imho ook wel redelijk resources vergen.

[Verwijderd]

Op dinsdag 19 maart 2002 14:56 schreef whoami het volgende:
Het openen van connecties zal toch imho ook wel redelijk resources vergen.

Een data connectie uit de pool staat al open dus dan kan ie gewoon direct 'n referentie naar toe geven dus kost iets minder, maar nog "duur" is vrij relatief in dit geval, heb je 'n distributed omgeving waar honderden clients query's dan is iedere seconde die je die database connectie vast houd idd duur (want ik neem niet aan dat je 100'en licenties hebt voor je sql/oracle server) maar als je met 'n beperkt aantal gebruikers met 'n 2 tier client server app naar je database connect who gives a shit dat je je connectie vast houd. In alle samples en boeken en shit wat er de laatste tijd uit komt wordt vrijwel alleen gesproken over de 3 tier aanpak waardoor veel mensen het idee krijgen dat dit de *enige* manier is wat zeker niet het geval is, je moet het gewoon praktish bekijken, heb je het nodig? wat is de toegevoegde waarde? wat zijn de evt kosten qua leer process en hoe makkelijk verloopt het onderhoud van je app in een later stadium. jah die samples van ms zijn wel geweldig en schaalbaar naar 1000'den users blah die blah maar ga je die 1000'den users krijgen dan!? moraal van dit verhaal denk zelf na en volg niet als 'n mak schaap de marketing machine van microsoft...

[whoami]

Op dinsdag 19 maart 2002 15:07 schreef Yarvieh het volgende:

moraal van dit verhaal denk zelf na en volg niet als 'n mak schaap de marketing machine van microsoft...

Dat doe ik ook niet, waarom zou ik anders hier de mening van anderen vragen?

[ACM]

connectionpooling heeft imho vooral nut als het relatief lang duurt voor de connectie er is en die normaliter relatief kort gebruikt wordt.

Voorbeeld is bijvoorbeeld een webaplicatie met Oracle als backend. 'Normaal' zou je de connectie openen, input verwerken, queries uitvoeren, resultaat verwerken, connectie sluiten.
Aangezien in dit geheel het uitvoeren van de query vaak maar een redelijk klein deel van de tijd opzich neemt bij de simpelere applicaties kost de connectie opening relatief het meeste tijd van het database gebeuren.

Als je nou al een stel 'general purpose' connecties open hebt raak je die connectie opening overhead kwijt. Om het dan nog wat efficienter te bouwen kan je er dan gelijk een goede pooling omheen maken.

Vaak heb je daadwerkelijk minder connecties naar je database nodig dan je er gebruikt in een webapplicatie (zeker als je php gebruikt ) en bij veel databases verspil je dan ook nog es flink wat resources (kostte oracle niet 2MB per connectie op de server zelf?) door te veel connecties.

Imho heeft connection pooling dus vrijwel altijd nut, als er sprake is van applicaties waar veel clients communiceren met een bepaalde ('centrale') (server)applicatie, waarbij die applicatie weer gegevens uit de ('centrale') DB moet trekken.

[whoami]

Ok, thx. Ik blijf dus bij m'n 'oude' manier: one connection to bind them all.

[Stephan Oudmaijer]

Op dinsdag 19 maart 2002 14:13 schreef whoami het volgende:
Ik zit met een dilemma.

Ik had graag eens geweten hoe jullie omgaan met database connections in desktop applications.

In Delphi ben ik gewoon om een TDatabase component te gebruiken en dmv dat TDatabase component een connectie te leggen met m'n databank die ik in het begin van m'n programma open, en pas weer sluit als mijn programma wordt afgesloten. De connectie met m'n databank blijft dus de hele tijd openstaan totdat de applicatie afgesloten wordt.

Nu ben ik bezig met C#/.net en hier was ik ook begonnen met 1 OleDbConnection of SqlConnection object te gebruiken en die connectie open te houden totdat m'n applicatie beëindigd wordt.
Nu heb ik het een en ander gelezen over connection pooling. Er wordt iedere keer een connection object aangemaakt en geopend wanneer dit nodig is, en vanzodra de query uitgevoerd wordt, wordt de connectie terug gesloten en naar een pool gestuurd. Als de applicatie dan op een later tijdstip opnieuw een connectie nodig heeft met de databank, dan kan er een connectie uit de pool gehaald worden en opnieuw geopend worden.

Nu had ik graag eens geweten hoe jullie het doen (in .Net of in Java). Wat zijn de voor- en nadelen van beide situaties?

zoals je het nu doet is in principe ideaal, ik heb echt een maand besteed aan onderzoek naar dit probleem. ConnectionPooling ( keb zelf een connectionPool systeem geschreven in java voor MySql en ODBC ) is alleen handig als je met veel mensen in dezelfde database zit te rommelen.

Van wat ik lees in jou posting doe je het nu perfect, maar dan moet je niet met meerdere mensen in dezelfde database gaan klooien.

[Stephan Oudmaijer]

Op dinsdag 19 maart 2002 16:03 schreef ACM het volgende:
connectionpooling heeft imho vooral nut als het relatief lang duurt voor de connectie er is en die normaliter relatief kort gebruikt wordt.

dit is altijd het geval, database connectie opzetten duurt altijd veel!!!!!!!!!! langer dan bestaande connectie gebruiken

Voorbeeld is bijvoorbeeld een webaplicatie met Oracle als backend. 'Normaal' zou je de connectie openen, input verwerken, queries uitvoeren, resultaat verwerken, connectie sluiten.
Aangezien in dit geheel het uitvoeren van de query vaak maar een redelijk klein deel van de tijd opzich neemt bij de simpelere applicaties kost de connectie opening relatief het meeste tijd van het database gebeuren.

Als je nou al een stel 'general purpose' connecties open hebt raak je die connectie opening overhead kwijt. Om het dan nog wat efficienter te bouwen kan je er dan gelijk een goede pooling omheen maken.

Vaak heb je daadwerkelijk minder connecties naar je database nodig dan je er gebruikt in een webapplicatie (zeker als je php gebruikt ) en bij veel databases verspil je dan ook nog es flink wat resources (kostte oracle niet 2MB per connectie op de server zelf?) door te veel connecties.

een slimme connectionPool werkt met een timeout mechanisme dus dit probleem is niet aan de orde

Imho heeft connection pooling dus vrijwel altijd nut, als er sprake is van applicaties waar veel clients communiceren met een bepaalde ('centrale') (server)applicatie, waarbij die applicatie weer gegevens uit de ('centrale') DB moet trekken.

[Verwijderd]

Persoonlijk open ik ook altijd bij het starten één connectie en die hou ik dan open tot het einde. Aangezien er toch hooguit 5 man tegelijk met m'n app gaan werken lijkt me dit helemaal geen probleem. Het is wel zo makkelijk .

[ACM]

Op woensdag 20 maart 2002 19:29 schreef CK het volgende:
dit is altijd het geval, database connectie opzetten duurt altijd veel!!!!!!!!!! langer dan bestaande connectie gebruiken

Bij mysql niet

een slimme connectionPool werkt met een timeout mechanisme dus dit probleem is niet aan de orde

Wat probeer je hiermee te zeggen ??

Ik geef aan dat het openen van 'te veel connecties' een probleem kan zijn voor je server (bijv omdat het veel resources trekt). Dat is iets dat je met connectionpooling kan afvangen.
En inderdaad, je moet uitkijken met je timeouts/gesloten connecties.

[Stephan Oudmaijer]

Op woensdag 20 maart 2002 19:36 schreef ACM het volgende:

[..]

Bij mysql niet
[..]

Wat probeer je hiermee te zeggen ??

Ik geef aan dat het openen van 'te veel connecties' een probleem kan zijn voor je server (bijv omdat het veel resources trekt). Dat is iets dat je met connectionpooling kan afvangen.
En inderdaad, je moet uitkijken met je timeouts/gesloten connecties.

juist ook bij mysql ! ik heb die connectiepool voor mysql gemaakt omdat de performance zo matig was...

een slimme connectionPool werkt met een timeout mechanisme dus dit probleem is niet aan de orde

hiermee zeg ik dus dat je niet teveel resources gebruikt omdat een slimme connectionpool z`n resources ook opruimt.

[ACM]

Op woensdag 20 maart 2002 23:34 schreef CK het volgende:
juist ook bij mysql ! ik heb die connectiepool voor mysql gemaakt omdat de performance zo matig was...

Bij mysql maakt het alleen veel minder uit dan bij postgres, oracle, etc.

een slimme connectionPool werkt met een timeout mechanisme dus dit probleem is niet aan de orde

hiermee zeg ik dus dat je niet teveel resources gebruikt omdat een slimme connectionpool z`n resources ook opruimt.

Ja, maar waarom zeg je dat nou?
DAT zeg ik toch ook?

Je vult me hooguit (goed) aan terwijl het lijkt of je me tegenspreekt.

Ik zie situatie1 : GEEN pooling -> vaak te veel resources door te veel open clients.
En situatie2 : WEL pooling -> oa het probleem van te veel clients opgelost (hopelijk).