Dobry den, Podle meho je nutne pouzit SELECT ... FOR UPDATE s volbou něco jako NOWAIT, kterou nemusi všechny databaze a hibernate dialecty podporovat...tj:
1) provest SELECT, ziskat exluzivni zamek bez cekani...v hibernate lze pouzit LockMode.UPGRADE_NOWAIT při nacitani entity...u ejb netusim... 2) nasledne provest, pokud se predchozi obeslo bez chyby, update... Další moznosti je nastavit v db (napr. primo na db tabulce, u AS400 to tak jde), jak dlouho se ma cekat na uvolneni zamku, který aplikovala jina transakce. Miroslav Tichý -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of František Končár Sent: Wednesday, August 27, 2008 10:57 AM To: [email protected] Subject: EJB a transakcie zdravim, v ramci vyuky s pomocou NetBeans a ich tutorialov som vytvoril J2EE aplikaciu (app client) ktora vyuziva EJB a Glassfish v2. Ako persistence providera som pouzil Hibernate a DB je Firebird. Riadenie transakcii som ponechal na kontajneri (CMP). Vsetko funguje OK az na konkurencne spracovanie zaznamov t.j ak zaznam zamknem (resp. zeditujem ale este nedam commit) napr. pomocou nejakeho GUI managera databazy a potom sa pokusam editovat ten isty zaznam cez moju aplikaciu aplikacia caka na zamknutie tohto zaznamu (deadlock) a zatuhne Da sa nejakym sposobom ovplyvnit chovanie transakcie resp. transakcneho managera tj ak sa mu nepodari zamkut zaznam pre editaciu nech na to necaka a hodi vynimku? (napr. v Delphi na to existuje parameter transakcie NOWAIT) Resp. ako sa riesi takato situacia? googlenim som nasiel nastavenie Glassfisha Transacion Timeout ale to podla mojich vyskumov zafunguje az potom ak transakcia zacala a neukoncila sa v casovom limite (vtedy poslusne dostanem hlasku: EJB5123:Rolling back timed out transaction ...) dakujem ---------- Dovolena do nejoblibenejsich mist za super ceny - www.myway.cz
