[Java lista] DBCP és szaporodó szálak

[Mariák Kálmán]

Köszönöm az észrevételt! 

Valóban zavaros, ez azért van, mert egy meglévő rendszert alakítottam át
jndi/dbcp alapúra, így a kereteket ez az előző pool vezérlés adja. A
legkevesebb refactoring-ot ez a megoldás biztosította. Nagyon sok
projekt használja ezt a keretet és, ha az alapvető szerkezeteket
megbolygatom akkor elkerülhetetlenül nagyon sok időt fog igénybe venni a
változások lekövetése. Ezeket a munkákat nagyon rosz szemmel szokták
nézni itt a cégben, mert a managment nem ért hozzá csak azt látják, hogy
pöcsölődök valamin amit nem lehet megfogni és eladni. :-(

A contextConnection-re én is gyanakodtam, azonban végig követtem a
használatát és nem találtam semmit ami ezt a tünetet idézhetné elő.
Holnap kipróbálom egy izolált környezetben a contextConnection vezérlés
nélkül aztán meglátom mit produkál. 

Lehet, hogy alap kérdés, de a request-ek után hogyan tudok filtert
futtatni? Nem mindig előtte futnak le láncban?

Mégegyszer köszi!

Mariák Kálmán

On Thu, 2011-02-24 at 22:59 +0100, Zsombor wrote:
> Helló,
> 
>  Elég zavaros ez az egész, nem értem miért kell ennyire
> túlbonyolítani, azaz ServletContext-be ConnectionPool, meg
> ConnectionPoolHandler osztályok. Elsőre pl azt nem látom, hogy miért
> nem zárja le a filter szépen az adatbázis kapcsolatokat legalább a
> request végén? Valamint miért akarja minden request, párhuzamosan is
> ugyanazt a kapcsolatot használni? Ez elég csúnya hibák forrása is
> lehet.
>  Ezt úgy szokták csinálni, hogy a Filter elején JNDI datasource-tól
> elkérnek egy kapcsolatot, azt beállítják egy ThreadLocal változóba,
> majd a filter tovább adja a vezérlést, s a végén amikor visszakapja,
> akkor meg törli a threadlocal-t és lezárja a kapcsolatot.
> 
> 
> Üdv
>  Zs