Re: JPA, optimimisticke zamykani a bezestavove update/delete
Ahoj, EntityManager muze byt bud transaction-scope (ten pouzivas) nebo extended (o tom pises v bode 2). Proc Ti vadi select, ktery se vykona v ramci merge? Zpusobuje vykonnostni problemy? Pokud ne, pak bych rad pripomnel zakladni pravidlo optimalizace: pokud nemusite, tak neoptimalizujte. Jinak vysledek toho selectu by se mel najit v cache (u TopLinku se to jmenuje second-level cache). Ne ze by mi to uplne vadilo, ale no krapet mne to znervoznuje. Zatim delam svoji prvni JPA aplikaci, ktera DB moc nezatizi, ale v budoucnu mozna budeme nasazovat JPA i pro aplikace, ktere naopak DB hodne zatezuji. Tak mne hlavne zajimalo, jestli nedelam neco spatne. BTW. k tomu zakladnimu pravidlu optimalizace: on potom ten software muze casem nabubret do takovych rozmeru, ze se pak nejak snadno optimalizovat neda. delam typickou CRUD web aplikaci pomoci JPA a jako DAO pouzivam stateless session beany. Na objektu pro JPA mam pomoci @Version oznaceny atribut pro optimisticke zamykani. Objekt ulozim v HttpSession kdyz se nacte z DB, uzivatel ho pak zmeni nebo vymaze. Pro update, resp. delete objektu pouzivam v stateless session beane: update: obj2 = em.merge(obj) delete: em.remove(em.merge(obj)); kde em je EntitytManager; Coz funguje, jak potrebuji, ovsem merge vzdy napred objekt nacita pomoci jednoho SELECTU: select ... from table t... where t.id = ? Po te se provede spravne UPDATE (nebo DELETE) s WHERE klauzuli kontrolujici verzi objektu. Ten prvni SELECT se mi zda zbytecny. Na webu jsem nasel jen dve reseni: 1. Pouzivat rucni UPDATE (DELETE), coz je hlavne pro UPDATE dost neprakticke. 2. Pouzivat statefull beany s nejakym rozsirenym modem pro persistence manager (nevim dost dobre, o co jde). Chtel bych se zeptat, jak je v tomto pripade spravny postup a jestli existuje nejake jednoduche reseni.
JPA, optimimisticke zamykani a bezestavove update/delete
DD, delam typickou CRUD web aplikaci pomoci JPA a jako DAO pouzivam stateless session beany. Na objektu pro JPA mam pomoci @Version oznaceny atribut pro optimisticke zamykani. Objekt ulozim v HttpSession kdyz se nacte z DB, uzivatel ho pak zmeni nebo vymaze. Pro update, resp. delete objektu pouzivam v stateless session beane: update: obj2 = em.merge(obj) delete: em.remove(em.merge(obj)); kde em je EntitytManager; Coz funguje, jak potrebuji, ovsem merge vzdy napred objekt nacita pomoci jednoho SELECTU: select ... from table t... where t.id = ? Po te se provede spravne UPDATE (nebo DELETE) s WHERE klauzuli kontrolujici verzi objektu. Ten prvni SELECT se mi zda zbytecny. Na webu jsem nasel jen dve reseni: 1. Pouzivat rucni UPDATE (DELETE), coz je hlavne pro UPDATE dost neprakticke. 2. Pouzivat statefull beany s nejakym rozsirenym modem pro persistence manager (nevim dost dobre, o co jde). Chtel bych se zeptat, jak je v tomto pripade spravny postup a jestli existuje nejake jednoduche reseni. Dik Ondra Medek
Re: JPA, optimimisticke zamykani a bezestavove update/delete
Ahoj, EntityManager muze byt bud transaction-scope (ten pouzivas) nebo extended (o tom pises v bode 2). Proc Ti vadi select, ktery se vykona v ramci merge? Zpusobuje vykonnostni problemy? Pokud ne, pak bych rad pripomnel zakladni pravidlo optimalizace: pokud nemusite, tak neoptimalizujte. Jinak vysledek toho selectu by se mel najit v cache (u TopLinku se to jmenuje second-level cache). Z.T. -- Zdenek Tronicek Department of Computer Science and Engineering Prague tel: +420 2 2435 7410 http://cs.felk.cvut.cz/~tronicek Cituji Ondra Medek xmed...@gmail.com: DD, delam typickou CRUD web aplikaci pomoci JPA a jako DAO pouzivam stateless session beany. Na objektu pro JPA mam pomoci @Version oznaceny atribut pro optimisticke zamykani. Objekt ulozim v HttpSession kdyz se nacte z DB, uzivatel ho pak zmeni nebo vymaze. Pro update, resp. delete objektu pouzivam v stateless session beane: update: obj2 = em.merge(obj) delete: em.remove(em.merge(obj)); kde em je EntitytManager; Coz funguje, jak potrebuji, ovsem merge vzdy napred objekt nacita pomoci jednoho SELECTU: select ... from table t... where t.id = ? Po te se provede spravne UPDATE (nebo DELETE) s WHERE klauzuli kontrolujici verzi objektu. Ten prvni SELECT se mi zda zbytecny. Na webu jsem nasel jen dve reseni: 1. Pouzivat rucni UPDATE (DELETE), coz je hlavne pro UPDATE dost neprakticke. 2. Pouzivat statefull beany s nejakym rozsirenym modem pro persistence manager (nevim dost dobre, o co jde). Chtel bych se zeptat, jak je v tomto pripade spravny postup a jestli existuje nejake jednoduche reseni. Dik Ondra Medek
