Aman, ljudi, ne secite ruku da biste lecili ogrebotinu. Najlakse resenje nije uvek i najbolje, umesto sto iskljucujete pooling, bolje dijagnostikujte odakle vam uospte dve konekcije. Otvaranje konekcije je najskuplji proces u radu sa bazom kako po klijenta tako i po server i ne treba iskljucivati pooling bez potrebe.
Pool nikad ne raste sam, prva konekcija otvara pool sa samo jednom konekcijom (osim ako connection string ne sadrzi "Min Pool Size" parametar, koji je po default-u 0). Ako je ta konekcija 'alocirana' (postoji ziv ADO.NET connection objekat nad njom) kreiranje novog sqlConnection objekta sa istim connection stringom dodaje novu konekciju u pool i tako pool raste. Ako pool nije prazan posle ClearPool() to znaci da ima sqlConnection objekata koji nisu zatvoreni.
Citat:
bunker: I posle ovoga ako pogledas broj konekcija prema bazi, dobicces najmanje dve. Ovo je stvar pooling-a. Imao sam probleme jednom prilikom sa restorovanjem baze iz aplikacije i mogu ti recci da sam ga resio na onaj nacin kao sto sam ti opisao. Iako sam konekciju drzao u singleton-u ipak su se pojavljivale dve. Da, radilo se o desktop aplikaciji, pa nisam imao potrebe za pooling-om.
Dok god postoje zivi sqlConnection objekti ClearPool nece izbaciti te konekcije iz pool-a. Singleton pattern je u ovom slucaju krivac za to posto drzi zivu instancu connection objekta tokom celog zivota procesa. Da bi se konekcija vratila u pool, Close ili Dispose mora biti pozvan. Moze isto lako da se desi da je negde kreiran sqlConnection objekat i onda nije eksplicitno zatvoren i otisao je off-scope, konekcija nece biti zatvorane dok god GC ne resi da unisti objekat i do tada konekcija ne odlazi nazad u pool. Da to dijagnostikujes, uradi GC.Collect(0) pre Clear Pool(), ako se problem resi onda imas taj bug negde u aplikaciji (good luck u trazenju).
Druga stvar, connection pool se kreira na nivou procesa po osnovu connection stringa, ne baze. Moguce je imati dva i vise poolova nad istom bazom u okviru istog procesa ili vise poolova u razlicitim procesima nad istim connection stringom, pa moze da se desi da restore pukne ioako je pool prazan zato sto neko drugi druzi otvorenu konekciju u drugom poolu/procesu nad istom bazom. Ovo je izrazito vazno za desktop aplikacije gde dva i vise korisnika rade paralelno.
U principu koriscenje singletona za cuvanje zivog connection objekta je losa praksa. Thread safety ode kroz prozor. Bolje drzati connection string u signletonu i metod koji kreira konekcije na zahtev. Tako imas centralizovanu kontrolu nad konekcijama i centralizaovanu kofiguraciju a zadrzavas slobodu.
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić