Hvor glemmer jeg at lukke en forbindelse

Aabner du altid connection i en using statement?

Hvis ikke saa skift til det!

Det gør jeg ikke, men jeg lukker altid i en finally, hvad skulle være bedre ved using, som jeg godt ved alle anbefaler?

Det er også muligt jeg vil gøre det, men lige nu vil jeg gerne finde ud af hvad der gør det her.
Jeg er forøvrigt begyndt at bruge noget Entity Framework i nogle situationer, kan det give den slags problemer?

i praksis er using en try med en finaly, altså det samme som det du gør, det er bare pænere og kræver mindre kode at bruge en using.

EF kan bruges på mange måder og kan for så vidt sagtens give denne slags problemer, det er dog kun et spørgsmål om hvordan du som udvikler har kodet dig ud af det præcis som med en "almindelig" connection.

Jeg kan  ikke lige komme i tanke om nogle af den type værktøjer omend de dog findes - men jeg tror at der hvor jeg oftest ser fejlen er når man åbner og lukker connections i et loop, måske det kan lede dig på vej i din applikation.

Et quick-fix er at forhøje din pool size hvis den ikke allerede er for høj.

Jeg har hævet Max Pool size til 200, men tænker at det er en stakket frist.

Ja jeg har været igennem en enkelt med løkke, men den gør som den skal, og det tror jeg altså det hele gør. Det eneste jeg kan være i tvivl om er EF.

Hvad er det nøjagtig der gør at ADO.NET laver en ny connection og smider i pool'en i stedet for at tage en af dem der er i pool'en i forvejen?

Den genbruger hvis connection string er præcis den samme.

Hvis du ikke lukker, så kan den ikke genbruge.

Bruger du DI/IOC? hvis, hvad framework?

EF har ikke disse fejl, så er jeg overbevist om flere ville have meldt tilbage til MS omkring det.

Kan du selv genskabe fejlen lokal eller sker det kun i prod?

Jeg kan se at jeg flere steder sætter Connection til null efter at have lukket den, hvad har det af betydning for det her?

Jeg har svært ved at genskabe det lokalt, for jeg ved stadig ikke helt hvilke kald der egentlig skaber det her.

Jeg tror heller ikke så meget på at det er EF

Burde ikke have noget at sige, men som de andre skriver, gør det emd using, så er der ingen tvivl om det altid bliver gjort korrekt.

Så med 'svært' mener du at det ikke har været muligt?

Hvis muligt, så er det jo bare at hamre siden flere gange på samme page ...

Hvad med DI/IOC?

Jeg bruger ikke DI/IOC.

Fejlen har ikke optrådt siden jeg lavede en lidt længere timeout og satte Max Pool size til 200.

Det jeg tænkte på med at jeg sætter connection til null, er at hvordan kan den genbruge en connection hvis den er sat til null?
Er det ikke det pool'en gør, genbruger connections?

Det du sætter til null er vel dit object i koden og ikke connectionen - det har kun noget at sige i dit applikations hukommelse. Når du kalder close lukkes connection - hvad det så præcist indebærer afhænger af opsætning; http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.close%28v=vs.110%29.aspx

Man kan ikke saette en connection til null.

Man kan saette en referance til en connection til null.

Connection eksisterer stadig.

Hvis der ikke er andre referancer til connection bliver den garbage collectet, men hvis der er referancer saa bliver den ikke GC'et.

Og connection pool har referance til connection.

Hej

Jeg fandt et sted i min åbning af connection hvor jeg i fejl situationer ikke fik lukket connection. Det ser ud til at have løst det.

Tak for hjælpen, hvis i svarer, kan i dele pointene.

Var det så et sted hvor der reelt opstod fejl eller var det kun en tænkt situation?

Af denne grund burde du måske pakke det ind i en hjælpe metode du kan genbruge ... så du undgår det i fremtiden :-)

mvh

Det jeg tænkte på med min kommentar var, at hvis der opstår en fejl og det åbenbart sker så ofte at det kan gå ud over performance, så er det måske ikke kunne en lukke-connection der skal tilføjes men måske noget validering eller lignende så fejl helt undgås.

Hej

Jeg skal generelt snart have gennemgået den del af koden, den er ført med fra første version. Dejligt at få lært ordentligt om det inden, så næste DBHandler-version bliver bedre.

Tak for svarene og kommentarerne