Tomu se rika "distribuovany deadlock" a ano, je to svina :-) Jeden z duvodu, proc synchronized je nutne pouzivat jen velmi opatrne, idealne vubec. Kamil Podlesak
-----Original Message----- From: [email protected] [mailto:[email protected]]on Behalf Of Rastislav Siekel Sent: Friday, February 27, 2009 8:43 AM To: Java Subject: [Fwd: Re: Oracle DataSource z 2 web applikacii] Musím si nasypať popol na hlavu, Oracle nemá problém. Ten bol, ako už asi tušíte, medzi stoličkou a klávesnicou. Kombinácia Oracle zámkov a synchronized metód je sviňa :-) Rastislav "Bedo" Siekel -------- Original Message -------- Subject: Re: Oracle DataSource z 2 web applikacii Date: Fri, 20 Feb 2009 11:09:17 +0100 From: Rastislav Siekel <mailto:[email protected]> <[email protected]> To: Java <mailto:[email protected]> <[email protected]> References: <mailto:[email protected]> <[email protected]> <mailto:[email protected]> <[email protected]> <mailto:[email protected]> <[email protected]> <mailto:[email protected]> <[email protected]> <mailto:[email protected]> <[email protected]> Predpokladám, že tam problém nevzniká. Ako som písal, získaný OracleDataSource predhodím Hibernate a viac sa o JDBC nestarám. Hibernate má zatvárať statement aj ResultSet a určite to tak robí, pretože to funguje. Tak isto ten autocommit - Hibernate pred každou transakciou loguje, "begin", "current autocommit status: true", "disabling autocommit" a po skončení transakcie "commit", "re-enabling autocommit", "committed JDBC Connection". Takže aj o toto sa Hibernate postará. Skúšal som nastaviť nejaké time-outy pre OracleDataSource a obmedziť max. počet connect-ov, ale bezvýsledne. Aplikácia aj naďalej niekedy neuvoľňovala zámky v DB. Až keď som zrušil druhú verziu aplikácie, všetko beží v poriadku - už tretí deň. Ak to bude bežať dobre naďalej, dovolím si tvrdiť, že Oracle má problém pri použití dvoch aplikácií, kde OracleDataSource sa pripája na ten istý dat. zdroj. (URL, meno, heslo), pokiaľ aplikácie bežia na Tomcat 6. Inštancie by mali byť oddelené cez iný classloader, ale očividne nie sú. Aspoň pri použití implicitnej cache. Díky moc, Rastislav "Bedo" Siekel P.S. Ešte ma napadlo, že je problém len v tom, že som nedal explicitný názov tej cache, takže Oracle zrejme vytvoril 2 objekty s rovnakým názvom. Ale cez iný classloader by tá identifikácia objektu mala byť jednoznačná. Toto som už ale netestoval. _____ Ing. Rastislav Siekel Prosoft s.r.o., Kuzmányho 8, 010 01 Žilina, Slovakia E-mail : <mailto:[email protected]> <[email protected]> Tel : 041/562 54 91 Fax : 041/562 54 97 Mobil : 0905 34 00 20 Jan Dvorak wrote: Taky je mozne, ze se nekde nezavre ResultSet (jako vysledek selectu), a tak databaze drzi s nim spojeny kurzor dele, nez by musela. Honza Dvorak Vladimír Náprstek napsal: Vzhledem k tomu čekání bych to spíš viděl na to, že nemáte autocommit a po insertu ora čeká na commit. Pokud pracujete s jednou aplikací, může se to asi snést (i když je to divné), ale u dvou už je větší pravděpodobnost, že na sebe operace takto narazí. Zkuste buď nastavit autocommit nebo si pohrát s transakcemi a ten commit dávat aplikačně (podle aplikace).
