[Javalist] Connection clean

[József Keresztes]

Az viszont simán elképzelhető hogy Oracle + Glassfish esetén jelentkezik ez
a probléma, ki fogom próbálni más környezetben is.

2016. április 27. 10:06 József Keresztes írta, <xesj.hu at gmail.com>:

> > Interneten azt irjak hogy a tranzakcio close/rollback is eldobja a
> lezaratlan cursor-okat. Es termeszetesen a connection.close()-nak is el
> kellene dobnia oket.
>
> > Kiprobalni nem tudom, mert nincs keznel Oracle.
>
> 1. Természetesen nem zárja le a rollback sem. Ha lezárná akkor az eredeti
> kérdést sem tettem volna fel ugyanis az én reményem az volt hogy tudok
> valami "connection javító" metódust hívni rögtön azután hogy kiveszek egy
> connection-t a pool-ból. DE nem tudok ilyet.
>
> És ahogy kivettem rögtön mondtam neki roolback()-et, setHoldability(0)-t
> de ezek nem javítják meg a dolgot, utána ha ResultSet-et akarok nem lehet.
>
> 2. Természetesen ha a glassfish pool-ban 8 connection van beállítva és
> abból 1 "rossz" akkor annak a programrésznek ami korrektül van megírva 1/8
> esélye lesz hogy keletkezik nála exception. Olyan mint az orosz rulett,
> kaphatsz kíváló connection-t is a pool-ból ha szerencséd van :)
>
> 3. Ezért természetesen csak úgy teszteltem a dolgot hogy a glassfish
> pool-ban csak 1 connection legyen, így pontosan lehet tudni melyiket kapom.
>
>
>
> 2016. április 27. 9:51 Suller Andras írta, <suller.andras at gmail.com>:
>
>> Szia!
>>
>> 2016-04-27 15:23 GMT+08:00 József Keresztes <xesj.hu at gmail.com>:
>> > Sziasztok !
>> >
>> > 1. A pool-ból kapott connection-t ha close()-zal zárjuk az természetesen
>> > semmiféle ResultSet-et, Statement-et nem zár le, ezt ki is
>> próbálhatjátok.
>>
>> Interneten azt irjak hogy a tranzakcio close/rollback is eldobja a
>> lezaratlan cursor-okat. Es termeszetesen a connection.close()-nak is
>> el kellene dobnia oket.
>> Kiprobalni nem tudom, mert nincs keznel Oracle.
>>
>>
>> > Annyi a hatása hogy visszakerül a pool-ba. Sőt nekem az a gyanúm ha egy
>> > nyitott tranzakció van, akkor aki újból kiveszi a pool-ból az tudja
>> > commit-álni vagy rollback-elni :), de ez utóbbiról azért nem győzödtem
>> még
>> > meg.
>>
>> Ez nagyon remelem hogy nem igy van. Ez azert durva biztonsagi kockazat
>> lenne.
>>
>>
>> > 2. Itt nálunk az Oracle-ben 200 cursor lehet, tegnap tesztelgettem, ez a
>> > default.
>> >
>> > 3. Valóban csak gány megoldások vannak, tegnap a glassfish-nél találtam
>> > olyan beállítást ami valóban ellenőrzi hogy a pool-ban visszatett
>> > connection-ban nincsenek lezárva Statement-ek és Resultset-ek, és ha
>> kérjük
>> > a glassfisht, akkor ezeket el tudja dobni. Erre két beállítás van, az
>> egyik
>> > hogy mennyi időközönként fusson az ellenőrzés, a másik pedig hogy
>> fusson-e.
>> > De ez valóban tákolmány szerintem.
>>
>> Ha production kodban van ez a gondod, akkor nem irigyellek, viszont
>> akkor alighanem gany megoldas is elfogadhato :) Legalabb ideiglenesen,
>> amig ki nincs javitva a kod, hogy azert ne doljon ossze a haz.
>> Probald esetleg lekerdezni a nyitott cursor-okat, peldaul:
>>
>>  select oc.sql_text, count(*)
>>    from v$open_cursor oc
>>    group by oc.sql_text
>>    having count(*) > 10
>>    order by count(*) desc;
>>
>>
>> > 4. Természetesen a hibát úgy lehet produkálni, hogy kivessszük a "rossz"
>> > connection-t a pool-ból, és ahogy az első ResultSet-et akarjuk nyitni
>> már
>> > exception keletkezik a túl sok nyitott ResultSet miatt. Ha várunk
>> perceket
>> > ez a connection akkor is szar lesz és a glassfish soha nem javítja meg
>> (na
>> > jó, nem vártam vele órákat), kivéve ha a glassfish-ben alkalmazzuk a 3.
>> > pontot, ami megjavítja:
>>
>> Amikor talalsz egy ilyen "rossz" connection-t, akkor az osszes tobbi
>> connection is rossz? Vagy azert van olyan, ami mukodik?
>>
>> Udv,
>> Andras
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20160427/62c37246/attachment.html>