Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

[Hibernate] fetch plan i strategija

[es] :: Java :: [Hibernate] fetch plan i strategija

[ Pregleda: 1819 | Odgovora: 1 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

anon315

Član broj: 315
Poruke: 1657
*.adsl-1.sezampro.yu.



+13 Profil

icon [Hibernate] fetch plan i strategija16.03.2008. u 15:45 - pre 195 meseci
Eksperimentisem sa fetch planovima i strategijama i dobijam jako cudne rezultate, makar u odnosu na ono sto nalazim u literaturi, pa reko' ajde da proverim sa vama gde je problem.

Fetch plan:

Odlucio sam se za ovakav plan - za sve many-to-one asocijacije postavljam lazy="false" na globalnom nivou iz prostog razloga sto su mi informacije iz one dela uvek potrebne kada imam many objekat.

Za kolekcije ostavljam default lazy, jer mi te informacije nisu uvek potrebne. Za proceduru / use case kada su mi ove informacije potrebne, dinamicki u HQL ili Criteria spojim sa joinom da bih dobio sta mi treba kako bih sa tim informacijama mogao da radim u detache-ovanom stanju.

Fetch strategija:

Analizom SQL-a koji Hibernate generise sam zakljucio par stvari:

Kada dohvatam many objekat imam jedan select za njega + n dodatnih selekta, gde je n broj many-to-one asocijacija koje taj objekat ima. Ok, to je i bilo za ocekivati. Medjutim, ja sada zelim da smanjim broj selecta, jer postoji situacija kada se ne dovata samo jedan takav objekat nego vise njih, sto rezultuje u poprilicnom broju selecta. Iz tog razloga umesto lazy="false" prelazim na fetch="join" sto bi za posledicu trebalo da ima automatsko ukljucivanje EAGER i pojavu samo jednog selekta sa inner join-ima. Ukoliko u sesiji dohvatim objekat sa get(), dobija se zeljeni rezultat. Medjutim, ukoliko do objekta dodjem preko HQL upita, imam samo jedan select, ali bez potrebnog joina. Onda u detache-ovanom stanju dobijam lazy exception. Resenje problema je da opet na nivou HQL-a ili Criteria uradim join. Ali onda ovo prestaje da bude globalna strategija. Dakle, fetch="join" funkcionise samo za get(). Jel moze neko da mi pojasni ovaj fenomen?

Idemo dalje, na nivou kolekcija sada zelim da poboljsam situaciju. Kada radim u sesiji i imam situaciju da dohvatim listu objekata koji imaju kolekciju i za svaki od tih objekata radim neko procesiranje koje koristi kolekciju. Tada dolazi do n+1 select problema - jedan select za dohvatanje svih objekata + po 1 select za dovatanje kolekcije svakog od objekata. Ovo se moze resiti prefetch-ovanjem u batch-evima ili subselect-tima. Ja se odlucijem za ovo drugo zbog logike "ako mi treba jedna kolekcija jednog objekta, trebace mi kolekcije svih" i u mapiranju kolekcije (set) postavljam fetch="select". Ocekujem da dobijem jedan select koji dohvata sve objekte i drugi select sa subselectom koji dohvata sve kolekcije za sve objekte. Medjutim nista se ne menja i dalje imam n+1 selekt. U cemu je stvar?

[Ovu poruku je menjao Vanja Petreski dana 17.03.2008. u 00:20 GMT+1]
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.adsl-1.sezampro.yu.



+13 Profil

icon Re: [Hibernate] fetch plan i strategija16.03.2008. u 23:15 - pre 195 meseci
1) HQL/Criteria ignorise globalnu fetch strategiju.

2) Grrr, typo - treba fetch="subselect"
 
Odgovor na temu

[es] :: Java :: [Hibernate] fetch plan i strategija

[ Pregleda: 1819 | Odgovora: 1 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.