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

[Peter Verhas]

Előtte indul el. Utána a filter dolga, hogy meghívja a láncban utána jövőt API-n keresztül doChain() . Amikor az visszatér az meg a lefutása után van.

Amíg nem csináltam ilyent én is azt gondoltam, hogy előtte és/vagy utána kerül meghívásra, és a filter visszatér, de nem. Sokkal jobb így. Akár még a request-et és a response-t is kicserélheted saját implementációra.



--
Verhás Péter
ügyvezető
Verhás & Verhás Szoftver Manufaktúra Kft.
peter at verhas.com
+36(30)9306805
skype: verhas




On 2011.02.24., at 23:27, Mariák Kálmán wrote:

> 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 
> 
> 
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist

--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20110224/2e0f8206/attachment-0001.html 
--------- következő rész ---------
Egy nem text típusú csatolt állomány át lett konvertálva...
Név: smime.p7s
Típus: application/pkcs7-signature
Méret: 6739 bytes
Leírás: nem elérhető
Url : http://javagrund.hu/pipermail/javalist/attachments/20110224/2e0f8206/attachment-0001.bin