JPA, optimimisticke zamykani a bezestavove update/delete

[Zdenek Tronicek]

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 <xmedeko na 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
>