<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="gmail_extra"><br><div class="gmail_quote">2016. április 27. 10:06 József Keresztes írta, <span dir="ltr">&lt;<a href="mailto:xesj.hu@gmail.com" target="_blank">xesj.hu@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><p>&gt; 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>&gt; 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 &quot;connection javító&quot; 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 &quot;rossz&quot; 
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 class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016. április 27. 9:51 Suller Andras írta, <span dir="ltr">&lt;<a href="mailto:suller.andras@gmail.com" target="_blank">suller.andras@gmail.com</a>&gt;</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 &lt;<a href="mailto:xesj.hu@gmail.com" target="_blank">xesj.hu@gmail.com</a>&gt;:<br>
&gt; Sziasztok !<br>
&gt;<br>
</span><span>&gt; 1. A pool-ból kapott connection-t ha close()-zal zárjuk az természetesen<br>
&gt; 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>
&gt; Annyi a hatása hogy visszakerül a pool-ba. Sőt nekem az a gyanúm ha egy<br>
&gt; nyitott tranzakció van, akkor aki újból kiveszi a pool-ból az tudja<br>
&gt; commit-álni vagy rollback-elni :), de ez utóbbiról azért nem győzödtem még<br>
&gt; meg.<br>
<br>
</span>Ez nagyon remelem hogy nem igy van. Ez azert durva biztonsagi kockazat lenne.<br>
<span><br>
<br>
&gt; 2. Itt nálunk az Oracle-ben 200 cursor lehet, tegnap tesztelgettem, ez a<br>
&gt; default.<br>
&gt;<br>
&gt; 3. Valóban csak gány megoldások vannak, tegnap a glassfish-nél találtam<br>
&gt; olyan beállítást ami valóban ellenőrzi hogy a pool-ban visszatett<br>
&gt; connection-ban nincsenek lezárva Statement-ek és Resultset-ek, és ha kérjük<br>
&gt; a glassfisht, akkor ezeket el tudja dobni. Erre két beállítás van, az egyik<br>
&gt; hogy mennyi időközönként fusson az ellenőrzés, a másik pedig hogy fusson-e.<br>
&gt; 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(*) &gt; 10<br>
   order by count(*) desc;<br>
<span><br>
<br>
&gt; 4. Természetesen a hibát úgy lehet produkálni, hogy kivessszük a &quot;rossz&quot;<br>
&gt; connection-t a pool-ból, és ahogy az első ResultSet-et akarjuk nyitni már<br>
&gt; exception keletkezik a túl sok nyitott ResultSet miatt. Ha várunk perceket<br>
&gt; ez a connection akkor is szar lesz és a glassfish soha nem javítja meg (na<br>
&gt; jó, nem vártam vele órákat), kivéve ha a glassfish-ben alkalmazzuk a 3.<br>
&gt; pontot, ami megjavítja:<br>
<br>
</span>Amikor talalsz egy ilyen &quot;rossz&quot; 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>