Názory k článku
Entity beans v JBoss a relace

vidim to jenom ja, nebo ma jeste nekdo jiny take pocit, ze tudy cesta nevede. Pripada mi to vsechno tak zbytecne komplikovane, nafoukle, vhodne pro skolici instituce. Deleat s tim levne software pro mensi zakazniky - jde to?

Jasne, rekl bych, ze vetsina Java aplikaci a java programatoru pouziva toto nebo primo Hibernate, takze ano.

Většina aplikací v Javě, které se dnes píšou, využívají objektově relačního mapování. Nevím co konkrétně vám připadá nafouklé a komplikované, mapování pomocí anotací (nebo xml) se provede jednou na začátku a ostatní kód je pak jednodušší, přehlednější a lépe udržovatelný než 'neobjektový' přístup při použití přímo JDBC API.

to je jen prvni dojem, staci se do toho ponorit a zmenite nazor ;-)

JJ, resit problemy s takovymi systemy je fakt lahudka. Obvikle to vypada tak, ze mi nekdo zavola a ma zadani: Nevime co vsechno jsme zmenili, nevime jake pouzivame indexy, nevime kteri uzivatele ted pouzivaji aplikaci, nevime co uzivatele v aplikaci delaji, nevime jake SQL dotazy nase aplikace provadi, nevime co vsechno zamykame a v jakem poradi, nevime kolik mame aktivnich sessions do DB, ale chyba je urcite na strane databaze a musite to rychle spravit. Takovehle technologie slibuji programatorum, ze nepotrebuji nic vedet o databazich. Bohuzel je to jen slib, ktery se neda splnit. Tohle se hodi jen pro male systemy s max. nekolika desitkami uzivateli.

Ale kdeze, na takychto systemoch bezia systemy s tisickami klientov.

Prevratna novinka ! Programator ktery nevi co dela zpusobil kolaps systemu. Vice se dozvite na TN.cz.

Prave preto uprednostnujem fyzicky oddelenu entitnu/servisnu vrstvu. Tam si to jednak dokazem lepsie postrazit (menej programatorov ale skusenejsich) na webe nech sa chlapci hraju s farbami a okrajmi.
Za druhe ale predpokladam ze asi potom nieco s tym zoznamom robil takze to mozno bolo aj optimalne. Za dalsie uz pri navrhu nerobit relacie obojsmerne a ked tak opacne z objednavky na partnera. Potom im to uz dojde ze musia pouzit nejaku sluzbu ktora sa da mozno optimalizovat.
Ale inac pekny bordel.

Inac napr. s Hibernatom je uplne najvtipnejsie ked vam niekto prepise (a nespravne) metody ako equals a hashCode. To je az ten spravny bordel a zle sa to hlada.

To je presne ono. Koho dneska zajima jaky je rozdil mezi "select * from" a select "count(1) from"?
Java neni spatny jazyk ale nema zadnou podporu pro paralelismus a zamykani(narozdil treba od archaickeho pl/sql) Tyhle programy jsou vyvijene jako jedno-uzivatelske a podle toho taky funguji. Ze zdrojaku takovehle aplikace se da tezko odvodit co se bude dit v databazi a jakym zpusobem potom databaze ovlivni ostatni uzivatele.

Java neni spatny jazyk ale nema zadnou podporu pro paralelismus a zamykani

Si robis srandu. Nepoznam jazyk ktory obsahuje tolko moznosti pre zamykanie a paralelizmus ako ma Java. Od low level java.util.concurrent.atomic az po high level struktury java.util.concurrent a java.util.concurrent.lock. Tam je uplne vsetko. Nie som taky dobry v PL/SQL, ako si tam zalozim dalsi thread?

A to si si z coho vylozil, z kariet? Ivan nehovori nikde o transakciach ani o isolation level. Ja ti poviem ze je vela programatorov ktory neovladaju ani Javu a to myslim veci ako genericke typy ich pouzivanie, nerozumeju zakladom objektovej dekompozicie, patternom, ktore v pl/sql pre istotu ani nemate a nemozte ich urobit.
Isteze kazdy by rad robil v teame samych profesionalov a nemusel sa pozerat ako niektori programatori koduju v style ktoremu ja hovorim "coding by accident". Najlepsie je napisat nazov nejakej suvisiacej premennej, buchnut tam bodku a stlacit CTRL+medzera. Potom si vyberu co sa tam najviac hodi, postup opakuju kym nie su spojny a idu dalej.
Ja robim vela z architekturami systemov, isteze musis mat v time niekoho kto sa v tom vyzna to ale neznamena ze KAZDY to musi vediet. Mas ludi ktory sa vyznaju vo frontendoch, Script enginoch, rule enginoch, BPML, SOA. Praca s DB nie je zas az taky science ako si myslite. Je to dolezite ale su to obycajne kazdodenne problemy projektu.
Mate programatorov ktory programuju frameworky, mapovanie do DB a niektori citaju specifikaciu a snazia sa to cele najako pochopit a pozliepat dokopy. To su problemy velkych projektov. Male projekty dajte robit radsej niekomu kto sa v tom naozaj vyzna.
Ja som pracoval na projekte kde sme aj v dev prostredi zriadovali stlpce v tabulkach cez DB specialistu ktoremu sme posielali dobre ze nie rovno SQL ktore sme si nemali ani kde vyskusat a ten imbecil bol schopny po dvoch dnoch vam to vratit ze tam chyba ciarka. Naco je taky DB specialista.
Nejako som sa rozpisal len som chcel povedat ze kazdy nieco vie a niektori nevedia nic a neurobite s tym obvykle nic lebo s nimi musite zit na projekte a v tom je to umenie vychadzat s ludmi.

Ooops, pattern je navrhovy vzor, a ako taky moze byt pouzity v lubovolnom programovacom jazyku.

Nie celkom, ak ti chybaju zakladne mechanizmy ako polyformizmus alebo riadenie threadov (ako napr v PL/SQL) tak ten pattern neurobis. Existuju objektove patterny ktore v struktorovanom jazyku neurobis.

Pokial vsetko funguje, a DB sa vojde do pamate, tak nie je problem. V momente ak DB narastie cez 1TB a pripajaju sa stovky pouzivatelov, tak je sakra dolezite ako je to napisane.

Teraz ma tu vsetci zabijete ale my sme raz mali vykonostny problem na aplikacii a bolo lacnejsie prikupit server ako to optimalizovat aj ked som bol proti. Cost efektivita nepusti. Samozrejme ze je dolezite ako je to napisane ale pomocou roznych nastrojov sa da zistit kde ti to koliduje alebo dlho trva. Tu sa da v Java pekne vyuzitelne AOP a na cas si nainjectovat kod nejakym performance aspectom. Ale inac suhlas.

nesuhlas. Je treba robit osvetu, skolenia, reviziu kodu, unit-testy, integracne testy.

Pokial to robis v domovskej firme tak OK. Zaujimavejsie je ked sa zide particka najomnych zoldnierov s 5tich roznych firiem plus domaci stuff a zacne sa robit 1.5 rocny projekt. Skus o niekom povedat ze je blbec a potrebuje skolenie. Zacnes byt ako nekooperujuci prvok vytlacany nech si ako chces dobry. Na takychto projektoch rozhoduje kto si a koho mas za sebou nie co vies. A k tomu politicka pretlacania jednotlivych firiem. Proste lahodka.

Jo presne tohle jsem myslel. Samozrejme ze vim ze java ma vlakna, zamky a vubec vsechno co takovy jazyk ma mit. Problem je v tom, ze si mnoho programatoru neuvedomuje, ze tim ze se pripoji k nejake databazi ovlivni praci tisicu uzivatelu, kteri pracuji s tou samou aplikaci. Kdyz v jave napisete "a.b=1;"
tak z toho nemate jak odvodit co se bude dit v databazi a hlavne nevite kolika uzivatelum znemoznite praci. Kdyz to porovnam se zastaralou, nemoderni architekturou klient-server (treba Oracle Forms)
tak muzu treba zjistit ze: "Uzivatel Vomacka, prihlaseny z PC JVOM pouziva modul aplikace XY, ma zamcenou radku v tabulce ABC a tim blokuje uzivatele Ruzickovu v modulu YZ". A cele mi to zabere asi 20 minut. Kdyz neco podobneho resim na aplikaci bezici na websphere tak to mam minimalne na tyden. To je pak mnohem jednodussi kazdou pulnoc spustit "killall java". Casto se stane, ze se chyba v aplikaci projevi v databazi. Kdyz ale tu databazi abstrahujete a nemate jasnou predstavu o tom co po te databazi vlastne chcete, tak se ty chyby velice tezko resi.

Relace, které mají na druhé straně N (tj. 1:N a M:N) se standardně načítají lenivě (viz specifikace, kapitoly 9.1.24 a 9.1.26). U vazby M:N je to dále v článku uvedeno, nicméně příklad s lenivým načítáním 1:N mi připadá matoucí (protože je to default).

Dále ještě doplním, že pokud bude velké množství relací fetchované eager, tak se v horším případě může stát, že se do paměti natáhne celá DB. V lepším případě se natáhne "pouze" velký strom objektů. Proti tomu se při použití JPA implementace v Hibernate lze bránit nastavením maximální hloubky, do které se rekurzivně entity fetchují eager (parametr hibernate.max_fetch_depth). Kromě toho je vhodné se zamyslet nad tím, jestli je skutečně potřeba vše fetchovat eager.

A ještě postřeh z používání JPA implementace v Hibernate. Eager fetch mi vždy fungoval pouze pokud jsem loadoval jedinou entitu (např. pomocí EntityManager.find nebo pomocí lenivého fetche relace N:1). Ve všech ostatních případech (např. dotaz vracející kolekci entit nebo lenivý fetch relace 1:N) byl load navázaných entit vždy lenivý bez ohledu na nastavení anotací. V případě dotazů to lze obejít pomocí fetch joinů, ale pozor na to, že potom může dojít k duplikaci záznamů. Nevím, jestli popsané chování je bug nebo feature, ve specifikaci jsem to nehledal, ale připadá mi celkem logické.

Zalezi ako velmi Enterprise to mate vyriesene. Pre male riesenia kde mate Webovu vrstvu pokope s entitnou v jednom virtualnom stroji je to OK. Ale pre velke enterprise riesenia kde mate skutocne entitnu/servisnu vrstvu separatne je lazy loading dobry iba pre sluzby, web uz si ich lazy nanataha. Taktiez pre riesenia s ESB (SOA) lazy velmi nepomoze.

RE:

V případě dotazů to lze obejít pomocí fetch joinů, ale pozor na to, že potom může dojít k duplikaci záznamů. Nevím, jestli popsané chování je bug nebo feature, ve specifikaci jsem to nehledal, ale připadá mi celkem logické.

Ahoj

Nie je my jasne preco dochadza k duplikacii zaznamov pri fetch joine???
(k duplikacii akych zaznamov? preco ti to pripada logicke?)

nejaky priklad by som odcenil...

Diq

ant

Pomůžu si citací ze specifikace (kapitola 4.4.5.3):

The following query returns a set of departments. As a side effect, the associated employees for those departments are also retrieved, even though they are not part of the explicit query result. The persistent fields or properties of the employees that are eagerly fetched are fully initialized. The initialization of the relationship properties of the employees that are retrieved is determined by the metadata for the Employee entity class.

SELECT d FROM Department d LEFT JOIN FETCH d.employees WHERE d.deptno = 1

A fetch join has the same join semantics as the corresponding inner or outer join, except that the related objects specified on the right-hand side of the join operation are not returned in the query result or otherwise referenced in the query. Hence, for example, if department 1 has five employees, the above query returns five references to the department 1 entity.

Za popsaných podmínek tedy tento dotaz vrátí 5 departmentů (5 krát ten samý), přestože department s číslem 1 existuje pouze jeden. Bez použití klauzule LEFT JOIN FETCH by se vrátil jediný záznam. Zaměstnance by bylo defaultně nutné dotáhnout lenivě.

Citovaný text zároveň říká, že při vyhodnocení dotazu se korektně dotáhnou relace podle nastavení v anotacích. Mnou popsané chování Hibernate tedy pravděpodobně byl bug nějaké starší verze. Zkoušel jsem to znovu a nyní se skutečně Hibernate chová v souladu se specifikací, takže se omlouvám za mystifikaci.

A proč mi to připadalo logické? Protože mám možnost si explicitně referencované entity dotáhnout pomocí fetch joinu, pokud to potřebuji, nebo je nedotahovat, pokud to nepotřebuji. Automatické dotažení entit nemusí být vždy efektivní. Např. pokud ve výše uvedeném příkladu budu mít Employees dotahované eager, tak Hibernate udělá jeden dotaz na Department a potom bude postupně dotahovat Employees po skupinách o velikosti hibernate.default_batch_fetch_size. Počet dotazů do DB je tedy lineárně závislý na počtu instancí entity Department. Tohle se žádnému DBA líbit nebude... Pokud se budou Employees dotahovat lenivě, tak se provede to samé, ale až při prvním přístupu ke kolekci Employees. Pokud tedy logika aplikace pracuje pouze s Departmenty, tak stačí jediný dotaz do DB.

aha, vdaka za objasnenie... :)

to, ze je vyslednych zaznamov 5 nieje prekvapujuce, je to proste to iste ako obycajny LEFT JOIN, akurat ze vyslednych employees nemas v select casti, ale su pekne vrateni cez Set v Department...