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. >> >>
