Avatar billede hulla Novice
13. januar 2014 - 09:57 Der er 13 kommentarer og
2 løsninger

Hvor glemmer jeg at lukke en forbindelse

Hej

Jeg har en ASP.NET applikation som tilsyneladende et eller andet sted ikke får lukket en connection (eller frigivet til Pool'en)
Jeg får ind imellem denne fejl:

"Timeout expired.  The timeout period elapsed prior to obtaining a connection from the pool.  This may have occurred because all pooled connections were in use and max pool size was reached.
"


Hvordan kan jeg finde ud af hvor i min applikation denne forbindelse ikke bliver lukket?

Jeg har tidligere læst om nogle tools der kunne spore den slags, men kan ikke finde noget om det nu.
Avatar billede arne_v Ekspert
13. januar 2014 - 15:17 #1
Aabner du altid connection i en using statement?

Hvis ikke saa skift til det!
Avatar billede hulla Novice
13. januar 2014 - 16:15 #2
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?
Avatar billede keysersoze Guru
13. januar 2014 - 17:12 #3
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.
Avatar billede hulla Novice
13. januar 2014 - 18:53 #4
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?
Avatar billede Syska Mester
14. januar 2014 - 08:50 #5
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?
Avatar billede hulla Novice
14. januar 2014 - 09:00 #6
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
Avatar billede Syska Mester
14. januar 2014 - 09:12 #7
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?
Avatar billede hulla Novice
14. januar 2014 - 14:27 #8
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?
Avatar billede keysersoze Guru
14. januar 2014 - 14:53 #9
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
Avatar billede arne_v Ekspert
15. januar 2014 - 03:30 #10
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.
Avatar billede hulla Novice
18. januar 2014 - 07:57 #11
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.
Avatar billede keysersoze Guru
18. januar 2014 - 08:53 #12
Var det så et sted hvor der reelt opstod fejl eller var det kun en tænkt situation?
Avatar billede Syska Mester
18. januar 2014 - 10:12 #13
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
Avatar billede keysersoze Guru
18. januar 2014 - 10:19 #14
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.
Avatar billede hulla Novice
18. januar 2014 - 18:28 #15
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
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester