<div dir="ltr"><div>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, <br></div>és csinálok 10000 lezáratlan ResultSet-et:<br><div><div><br> int count = 10000;<br> ResultSet[] rt = new ResultSet[count];<br> for (int i = 0; i < count; i++) {<br> rt[i] = connection.prepareStatement("SELECT value FROM xxxx limit 5").executeQuery();<br> rt[i].next();<br> }<br><br></div><div>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.<br><br></div><div>Valszeg az Oracle 100-szor érzékenyebb lélek :)<br></div><div> <br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016. április 27. 10:12 József Keresztes írta, <span dir="ltr"><<a href="mailto:xesj.hu@gmail.com" target="_blank">xesj.hu@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016. április 27. 10:06 József Keresztes írta, <span dir="ltr"><<a href="mailto:xesj.hu@gmail.com" target="_blank">xesj.hu@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><p>> 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.</p>
<p>> Kiprobalni nem tudom, mert nincs keznel Oracle.</p></span><p>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.<br></p><p>É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.</p><p>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 :) <br></p><p>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. <br></p><p><br></p></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016. április 27. 9:51 Suller Andras írta, <span dir="ltr"><<a href="mailto:suller.andras@gmail.com" target="_blank">suller.andras@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Szia!<br>
<span><br>
2016-04-27 15:23 GMT+08:00 József Keresztes <<a href="mailto:xesj.hu@gmail.com" target="_blank">xesj.hu@gmail.com</a>>:<br>
> Sziasztok !<br>
><br>
</span><span>> 1. A pool-ból kapott connection-t ha close()-zal zárjuk az természetesen<br>
> semmiféle ResultSet-et, Statement-et nem zár le, ezt ki is próbálhatjátok.<br>
<br>
</span>Interneten azt irjak hogy a tranzakcio close/rollback is eldobja a<br>
lezaratlan cursor-okat. Es termeszetesen a connection.close()-nak is<br>
el kellene dobnia oket.<br>
Kiprobalni nem tudom, mert nincs keznel Oracle.<br>
<span><br>
<br>
> Annyi a hatása hogy visszakerül a pool-ba. Sőt nekem az a gyanúm ha egy<br>
> nyitott tranzakció van, akkor aki újból kiveszi a pool-ból az tudja<br>
> commit-álni vagy rollback-elni :), de ez utóbbiról azért nem győzödtem még<br>
> meg.<br>
<br>
</span>Ez nagyon remelem hogy nem igy van. Ez azert durva biztonsagi kockazat lenne.<br>
<span><br>
<br>
> 2. Itt nálunk az Oracle-ben 200 cursor lehet, tegnap tesztelgettem, ez a<br>
> default.<br>
><br>
> 3. Valóban csak gány megoldások vannak, tegnap a glassfish-nél találtam<br>
> olyan beállítást ami valóban ellenőrzi hogy a pool-ban visszatett<br>
> connection-ban nincsenek lezárva Statement-ek és Resultset-ek, és ha kérjük<br>
> a glassfisht, akkor ezeket el tudja dobni. Erre két beállítás van, az egyik<br>
> hogy mennyi időközönként fusson az ellenőrzés, a másik pedig hogy fusson-e.<br>
> De ez valóban tákolmány szerintem.<br>
<br>
</span>Ha production kodban van ez a gondod, akkor nem irigyellek, viszont<br>
akkor alighanem gany megoldas is elfogadhato :) Legalabb ideiglenesen,<br>
amig ki nincs javitva a kod, hogy azert ne doljon ossze a haz.<br>
Probald esetleg lekerdezni a nyitott cursor-okat, peldaul:<br>
<br>
select oc.sql_text, count(*)<br>
from v$open_cursor oc<br>
group by oc.sql_text<br>
having count(*) > 10<br>
order by count(*) desc;<br>
<span><br>
<br>
> 4. Természetesen a hibát úgy lehet produkálni, hogy kivessszük a "rossz"<br>
> connection-t a pool-ból, és ahogy az első ResultSet-et akarjuk nyitni már<br>
> exception keletkezik a túl sok nyitott ResultSet miatt. Ha várunk perceket<br>
> ez a connection akkor is szar lesz és a glassfish soha nem javítja meg (na<br>
> jó, nem vártam vele órákat), kivéve ha a glassfish-ben alkalmazzuk a 3.<br>
> pontot, ami megjavítja:<br>
<br>
</span>Amikor talalsz egy ilyen "rossz" connection-t, akkor az osszes tobbi<br>
connection is rossz? Vagy azert van olyan, ami mukodik?<br>
<br>
Udv,<br>
Andras<br>
<div><div>_______________________________________________<br>
Javalist mailing list<br>
<a href="mailto:Javalist@lists.javaforum.hu" target="_blank">Javalist@lists.javaforum.hu</a><br>
<a href="http://lists.javaforum.hu/mailman/listinfo/javalist" rel="noreferrer" target="_blank">http://lists.javaforum.hu/mailman/listinfo/javalist</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>