U jakeho presne driveru jsem se s problemem nezavirani RS setkal si jiz nepamatuji. Dost mozna i ten zminovany Oracle OCI driver.
Ono zavisi hodne na kontextu a zpusobu pouziti PS a RS. Pokud napriklad otevirate z jednoho PS vice result setu, jak intepretovat ponekud vagni javadoc u Statement.close "When a <code>Statement</code> object is closed, its current <code>ResultSet</code> object, if one exists, is also closed." Jaky z tech x otevrenych RS je ten "current"? Jsou to a) vsechny b) posledni otevreny c) posledni iterovany Jak jsem psal, PS jsou navic casto cachovany, takze pokud volate PS.close ve finaly, nemusi to ale VUBEC znamenat, ze se Vam zavrou result sety asociovane s tim PS, protoze jeho close metoda se v zaveru ani nezavola (zavola se close na nejakym wrapperu, ktere ten PS POUZE vrati do poolu). Tj. shrnuto podtrzeno, RS zavirat vzdy explicitne a neni problem. Spolehat na PS.close/finalizator apod -> povesit programatora za usi do pruvanu. Off topic: S tim Oracle driverem jsme mi pripomnel jinou perlu jejich driveru. Pri praci s LOBy se musely PS castovat na Oracle specificke implementace, aby bylo mozne volat metody pro praci s LOBy. Standardni java.sql.Clob/Blob nefungovaly. Doufam, ze uz s tim neco udelali... toto bylo pred cca 3 roky. Honza -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Artur Linhart - Java Communication Sent: Thursday, August 24, 2006 10:46 AM To: Java Subject: Re: for vs. while - problemy s SQL Drivery .Myslim, ze s nejakym podobnym nestandardnim chovanim jsme se setkali v pripade Oracle 9.2.0.1 driveru, ktere obsahovaly mimo jine i nekolik chybek v tehle oblasti. Uz je to dele, ale problem byl mam dojem nejen s uzaviranim pripojeneho resultsetu, ale i s tim, ze se sam statement neuvolnoval korektne ackoliv by podle standardu mel pote co se spusti garbage collector - urcite se vyplaci volat close primo na statementu stejne jako predtim na resultsetu ktery byl pres statement vytvoren. Prestoze javadoc u metody java.sql.Statement.close() tvrdi "A <code>Statement</code> object is automatically closed * when it is garbage collected. When a <code>Statement</code> object is * closed, its current <code>ResultSet</code> object, if one exists, is * also closed. " - nemusi byt obecne pravda ani prvni, ani druha veta, holt jako vzdy zalezi na tom, jak se ten interface naimplementuje. Takze pokud si nejste stoprocentne jisti (coz neni asi nikdy :-) ) tak by se ten close mel asi volat vsude kde to jde... Jinak - slo o oci8 driver, mozna ze u nativniho, ktery bohuzel pouzivat nemuzeme, to funguje spravne, to nevim... Uz je to sice hodne off topic od puvodniho tematu, ale napada mne napr. mimodek i dalsi chyba na kterou jsme narazili v Oracle driverech se kterou jsme se opravdu hodne hodne vyvztekali nez jsme na ni prisli - a to je problem s datovym typem timestamp a jeho prevodem na javovsky Timestamp, u ktereho se v pripade, ze je pocet milisekund nacteny z databaze 0 jako pocet milisekund "naindukuje" jine cislo nezli 0. Jinymi slovy, jak mi pomohl kolega Michal s upresnenim: pri cteni Timestamp s 0 ms je vracena hodnota ms z posledniho cteneho Timestampu ktery mel ms <> 0. Jednoduse, pokud tam bylo 0 ms, tak ten driver jakoby ten udaj "ms" nijak nemenil, takze tam zustala predesla hodnota. - tzn. pokud napr. pouzivate Oracle timestampy k overeni, jestli se Vam zaznam nezmenil v mezidobi mezi dvema selecty, je dobre na podobne policko pripojit primo na urovni databaze trigger, ktery nejenom ze pri updatu nastavuje vzdy aktualni hodnotu casu, ale v pripade, ze pocet milisekund je 0, tak je trosicku postrci o milisekundu, aby nacitani pres JDBC do typu Timestamp potom fungovalo spravne - my to delame momentalne takhle: create or replace trigger TU_BC_COUNTRY before update on BC_COUNTRY for each row declare locMs int; loc_current_GMT_timestamp TIMESTAMP(3); begin loc_current_GMT_timestamp := current_timestamp at time zone 'GMT'; :new.CHANGE_DATE := loc_current_GMT_timestamp; locMs := mod(extract(second from :new.CHANGE_DATE) * 1000, 1000); if (locMs = 0) then -- tady je to postrceni o milisekundu, pokud je pocet milisekund roven 0: :new.CHANGE_DATE := :new.CHANGE_DATE + numtodsinterval(0.001, 'SECOND'); end if; :new.CREATE_DATE := :old.CREATE_DATE; :new.CREATE_USER_LOGIN := :old.CREATE_USER_LOGIN; end; / neprisli jsme na jiny zpusob jak se s tim vyporadat. U verze 10.2 oracle driveru snad uz je to opravene... Ahoj, Archie. -..--- Original Message ----- From: "Roman Kratochvil" <[EMAIL PROTECTED]> To: "Java" <[email protected]> Sent: Wednesday, August 23, 2006 8:42 PM Subject: Re: for vs. while To, ze je to zrovna ResultSet, byl jenom priklad, o to mi primarne neslo. Nicmene faktem je, ze jsem se zatim nesetkal (troufam si tvrdit) s JDBC driverem, ktery by ty ResultSety nezaviral pri zavreni Statementu (ten samozrejme zaviram ve finally...). Delal jsem s MSSQL2000, 2005 (drivery od MS i jTds), MySQL 3.x, 4.x (drivery org.gjt.mm.mysql* i com.mysql.*), HSQLDB 1.7.x. Myslim, ze i s Oracle 8.5 nebyl problem, ale to uz je davno, mozna se pletu (resp. mozna to tehdy bylo psane jinak). Mohl bych se poucit, s jakymi DB/drivery jste zazili problemy? Diky Roman ----- Original Message ----- From: "Moravec Jan" <[EMAIL PROTECTED]> To: "Java" <[email protected]> Sent: Wednesday, August 23, 2006 5:29 PM Subject: RE: for vs. while > No jo, ale ve finally ten RS nezavrete, kdyz to je lokalni promenna toho > cyklu. Takze v ty podobe v jake to bylo presentovano, tj. > > for (ResultSet res=...; res.next(); ) > { > } > > je to spise hezky antipattern. > > H. > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Stanislav Ošmera > Sent: Wednesday, August 23, 2006 4:41 PM > To: Java > Subject: Re: for vs. while > > > On 8/23/06, Moravec Jan <[EMAIL PROTECTED]> wrote: >> Zdravim, >> >> Asi jsem neco nepochopil, ale jak korektne uzavrete ten otevreny result >> set bez toho, ze byste spolehal na to, ze se to "mozna udela samo" pri >> zavirani prepared statementu? >> >> Nedoporucuji na prilis spolehat na to, ze se ResultSet uzavre v okamziku >> uzavreni statementu (to rika javadoc u ResultSet.close). > > Presne, drive jsem se na to spolehal az jsem jednou dost narazil a > musel to prepisovat vsude. Myslim mozna ze je to napsano i v tom > Blochovy ze resultset vzdy zavirat ve finally bloku, nikdy se > nespolehat na zadnou automatiku > > > -- > Stanislav Ošmera > Work: +44 (0)2075 980 348 > Cell: +44 (0)7914 635 412 > private email: [EMAIL PROTECTED] > work email: [EMAIL PROTECTED] > Skype: sosmera ICQ:149634231 >
