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
