Új hozzászólás Aktív témák

• #6234 floatr veterán Szmeby #6229

  Új Válasz 2014-10-03 10:27:26 #6234

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz Szmeby #6229 üzenetére

  A filter annyit csinál, hogy egyazon session-t fog visszaadni a request idejére. Ez akkor kellhet, ha lazy collection-öket használsz, de nem inicializálod őket a betöltéskor. Ilyenkor session hibával hanyatt esik az egész.

  A tranzakció egy kicsit más, azt definiálhatsz többet is pl. annotációval a business layer-ben. Ha egy controller több business metódust használ, akkor több tranzakció is kifuthat menetközben.

  (#6230) jetarko nem lassabb lesz, hanem néha feleslegesen végzi a munkát, több memóriát ehet stb. Amikor EAGER-nek definiálsz egy kapcsolatot, akkor a tulaj betöltése nem egy szimpla select lesz, hanem hozzáfűzi az összes kapcsolatot, és egy menetben tölti be az adatokat.
  Amikor a size() metódust használod LAZY-vel, akkor külön SQL fut le a collection-re.

  Ami duplikálódást illeti, asszem itt már azért látszódik, az oka az egésznek. EAGER az összes kapcsolatod, ezért szépen sorban hozzáfűzi JOIN-nal a TEAM táblához a lekérdezésnél. 1 join esetében a TEAM duplikálódik, minden további join esetében viszont a hozzáfűzött táblák rekordjai is. Itt lehet kutya elásva. Valószínűleg több collection is duplikált adatokat fog tartalmazni emiatt az összesített SQL miatt. Amikor a példámban néztem, nekem csak egy one-to-many kapcsolatom volt, amiben a tulaj szűrve volt, a collection elemei pedig egyszer jöttek a select-ből. Ha több ilyen van, akkor a select egyszerűen ilyen hulladék eredményt ad.

  Emiatt is érdemes lenne subselect-eket használni valamilyen módon. Mondom, én a filtert javaslom LAZY-vel

Új hozzászólás Aktív témák