[Javalist] Connection clean

[József Keresztes]

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.
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.

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.

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:


Glassfish beállítás: JDBC Connection Pools -> Connection Settings



*Statement Leak Timeout: 10 Seconds*

*Statement Leak Reclaim: igen  *

Amúgy van olyan beállítás is hogy connection leak timeout...

Joe

2016. április 27. 4:59 Suller Andras írta, <suller.andras at gmail.com>:

> Nem irtad, hogy ez a hiba az elso select lefuttatasakor jon-e elo,
> vagy a kesobbiek folyaman? Determinisztikusan elo tudod-e idezni ezt a
> hibat?
>
> A default beallitasokkal 50 cursor lehet megnyitva egyszerre. Ezt
> normal mukodes kozben sem olyan nehez elerni, szoval elso korben
> megemelnem ezt az erteket, aztan hatha ez megoldja.
> Ahogy Adrian irta, a connection pool valoszinuleg lezarogatja a
> resultset-eket, ez nem kellene hogy gondot okozzon.
>
> Bovebb info pl itt:
>
> https://stackoverflow.com/questions/2560350/oracle-doesnt-remove-cursors-after-closing-result-set/
>
> Andras
>
>
> 2016-04-26 20:30 GMT+08:00 József Keresztes <xesj.hu at gmail.com>:
> > Sziasztok !
> >
> > Van egy webalkalmazás, az Oracle adatbázis kapcsolatok pool-ban
> üldögélnek.
> > Az egyik folyamat kivesz egy Connection-t a pool-ból, de abban nincsenek
> > tisztességesen lezárva a ResultSet-ek, így amikor szerencsétlen szeretne
> egy
> > ResultSet-et kapni akkor az Oracle beint neki:
> >
> > java.sql.SQLException: ORA-01000: maximum open cursors exceeded
> >
> > A kérdés lerágott csont, természetesen úgy kell programozni hogy mindig
> > mindent szépen lezárunk stb stb stb.
> >
> > DE ! Tényleg nincs arra mód hogy amikor valaki kivesz a pool-ból egy
> > connection-t akkor valami "tisztogatás" félét hajtson végre rajta, tehát
> > rögtön ezzel kezdjen, és így függetlenné váljon attól hogy milyen
> állapotú
> > connection-t hagytak neki a pool-ban ? Sajnos hiába kezd rögtön
> rollback-el,
> > vagy setHoldability(0)-lal, ez nincs hatással rá. Valszeg nincs is rá
> > megoldás, de hátha Ti mégis megoldottátok ezt a dolgot.
> >
> > Joe
> >
> > _______________________________________________
> > Javalist mailing list
> > Javalist at lists.javaforum.hu
> > http://lists.javaforum.hu/mailman/listinfo/javalist
> >
> _______________________________________________
> 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/1dc76728/attachment.html>