[Javalist] Connection clean

[József Keresztes]

Kipróbáltam a Glassfish + PostgreSQL kombinációt. A probléma elő sem jön,
de még úgy sem ha trehányul programozok,
és csinálok 10000 lezáratlan ResultSet-et:

        int count = 10000;
        ResultSet[] rt = new ResultSet[count];
        for (int i = 0; i < count; i++) {
          rt[i] = connection.prepareStatement("SELECT value FROM xxxx limit
5").executeQuery();
          rt[i].next();
        }

Se így nem keletkezik exception se úgy, hogy ezt a connection-t később
kiveszem a pool-ból és újra kérek 10000 ResultSet-et.

Valszeg az Oracle 100-szor érzékenyebb lélek :)


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

> 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/abff915d/attachment.html>