[Javalist] Connection clean

[József Keresztes]

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