Ahoj, >> Neni mi jasne jaky je rozdil v pouziti DTO vs inicializace, pokud to >> kopirujete z business modelu do DTO, >> tak proste jenom misto kopirovani provadejte inicializaci ...??? > > To ano, ale kdyz mam DTO, tak nehrozi LazyInitializationException. S touto > vyjimkou si view "poradi" tak, ze uzivatel skonci na error strance a smytec a > vy musite aplikaci urychlene fixovat a pak zdlouhave znovu testovat, > nasazovat apod. Momentalne nejsem v situaci, kdy bych chtel venovat moc casu > opakovanemu testovani, ci psani a udrzovani testovacich casu (jsem na tu > aplikaci sam :). Cili v tomto smyslu pokladam DTO za robustnejsi reseni.
jasne, takze je mensi bolest zobrazit null, nez se dozvedet, ze je neco spatne, aha ... >> Samozrejme se to da resit selektivne (asi ne u portalu), ale u normalni >> aplikace vim, cca. jaka view budou nasledovat >> a pak jsem schopen rici, ze u view, kdy se pouze generuje vystup neni >> problem nechat otevrenou read-only transakci >> a pockat az se to vygeneruje. U jinych muzu business model nainicializovat a >> zavrit transakci, tj. zadne dalsi dotahovani z db. > > Moc pracny IMO. View se ruzne upravuje a sledovat co se z nej vola a jak se > co taha je u slozitejsich aplikaci nad moje sily. Co testy ?? Pokud mas napr. integracni testy v seleniu, pak ti testy spadnou a z vyjimky hned vis co je spatne ... a deje se to automaticky ... >> To bude priserne pomale ... chytat vyjimky, asociaovat objekty s novymi >> sessionami a pak je dotahavat ... > > Proc myslite? Vytoreni nove session by melo byt celkem jednoduche, je to > koneckoncu jenom takovy wrapper nad db spojenim. Alokace db spojeni z poolu > taky nic tragickeho. Asociace objektu se session taky nic moc nedela, > vyprazdneni session a jeji uzavreni s tim, ze se nic neuklada by mela byt > taky jednoducha operace. Jediny co muze trvat nejdele je vlastni db dotaz a > to uz je celkem jedno, zda ho delam v nove session, nebo ve stavajici > session. Jde typicky o nekolik jednotek az desitek takovychto volani na > stranku (seznam kontaktu k uzivateli, seznam firemnich nastaveni apod). Pokud > by se mely tahat nejake dlouhe seznamy, tak samozrejme radeji pouziji nejake > DTO naplneny jednim dotazem a Hibernate ani nepouziju. No jde o to kolik takovych vyjimek za dobu vytvoreni view bude, protoze vyhozeni vyjimky vcetne stacktracu neni "levna" zalezitost, to uz mozna bude jednodussi tam namontovat nejakej interceptor, ktery by poznal, ze se snazite neco dotahnout a tam vcas zasahnout ... pokud to jde > Misto chytani vyjimek zkusim AOP interceptor nad get* metodama domenovych > objektu s tim, ze pokud interceptor zjisti, ze je getter volany mimo JPA > transakcni kontext (tj. mimo kontext, kde se mi vazby dotahuji sami) a objekt > vraceny z prislusneho getteru je proxy ci proxy kolekce, tak otevru (pokud > neexistuje) novou Hibernate session (flush=never, release after > statement=true) a dany objekt objekt automaticky dotahnu a vratim. > > Vyhody: naprosto transparentni reseni z pohledu view, db spojeni alokovano > jen na nezbytne nutnou dobu > Nevyhody: drobny cpu overhead proti rucnimu volani session.initialize() Jo to je docela pekne reseni ... otazka je, zda budete schopen vytvorit sessionu s release-after-statement=true, protoze se ukazuje, ze se to dava do SessionFactory pres Setting, a tim "znicite" SessionFactory. Mozna by slo mit 2 SessionFactory, jednu pro view (bude mit release-after-statement=true) a druhou na provadeni business logiky. > Nezapomente, ze bottleneck byva typicky db, nikoli cpu. Kdyz se mi nebude > dostavat cpu pridam dalsi cpu, ci rovnou novy stroje do klusteru. Investice > radove desitky tisic. Kdyz nebude stihat db, mam problem (neni bohuzel moc > pravidlem, ze db je mozny jednoduse klusterovat - maximalne tak funguje > failover, ale rozlozeni zateze na vice db stroju se synchronni replikaci dat > je dost problem). To je zase jina pohadka, tu si nechma na priste :-) Jirka > -----Původní zpráva----- > Od: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] za uživatele Jiri Mares > Odesláno: Tuesday, June 12, 2007 11:47 > Komu: Java > Předmět: Re: Hibernate aneb jak se (ne)vyhnout DTO > > > > Ahoj, > >> Tu inicializaci asociaci pred commitem jsem taky delal, ale clovek i >> presto, na muj vkus prilis casto, resi LazyInitializationException >> diky tomu, ze se metoda vola z ruznych kontextu, kde jsou potreba >> ruzna data (takze tokonci tak, ze clovek pridava dalsi a dalsi >> session.initialize()). Neprijemny side-efekt je pak i to, ze se nekde >> dotahuji data, ktera by se v danem kontextu dotahovat vubec nemusela. >> Tohle mi prijde neuhlidatelne, proto jsem (doufam ze jen) docasne >> zvolil cestu DTO a to i za cenu zvysene pracnosti. > > Neni mi jasne jaky je rozdil v pouziti DTO vs inicializace, pokud to > kopirujete z business modelu do DTO, tak proste jenom misto kopirovani > provadejte inicializaci ...??? > > > >> Myslenka s dvema transakcema per session me pred casem taky napadla, >> nebo jsem to mozna nekde cetl. Akorat me dost desi, ze db spojeni >> zustane alokovano po celou dobu renderovani view, coz je vec, kterou >> ovlivni i rychlost spojeni klienta (pokud mi 100 lidi posle request na >> aplikaci a nebudou pak cist response, nebo jen velmi pomalu a dojde na >> strane serveru z zaplneni bufferu, budu mit v aplikaci razem blokovano >> 100 spojeni). Tuto vlastnost ma samozrejme i to reseni se dvema >> session. > > Samozrejme se to da resit selektivne (asi ne u portalu), ale u normalni > aplikace vim, cca. jaka view budou nasledovat a pak jsem schopen rici, ze u > view, kdy se pouze generuje vystup neni problem nechat otevrenou read-only > transakci a pockat az se to vygeneruje. U jinych muzu business model > nainicializovat a zavrit transakci, tj. zadne dalsi dotahovani z db. > >> Z meho pohledu idealni reseni by byl nejaky interceptor na >> LazyInitializationException, ktery by dostal referenci na >> problematicky objekt, otevrel by session, dotahl by co potrebuje, >> session zase rychle zavrel a uvolnil tim alokovane db spojeni. Ale >> toto se obavam neni Hibernate podporovano, ale zase nejsem takovy >> Hibernate guru. Kazdopadne tuto moznost aktualne zkoumam. > > To bude priserne pomale ... chytat vyjimky, asociaovat objekty s novymi > sessionami a pak je dotahavat ... > > Nevim, asi mam jednoduchy business model, ale dotahnout vse potrebne dopredu > mi zatim nedele problemy. Nelibi se mi, a proto to zkusim zmenit ... > > Jirka > >> -----Původní zpráva----- >> Od: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] za >> uživatele Jiri Mares >> Odesláno: Tuesday, June 12, 2007 10:12 >> Komu: Java >> Předmět: Re: Hibernate aneb jak se (ne)vyhnout DTO >> >> resim podobny problem, lepe receno kdo ne .... >> >> Ja jsem na to zatim sel tak, ze vim, co view potrebuje a tyto >> asociace, ci lazy dotahavane property nainicializuji pred commitem >> transakce, tj. dotahnu do business objektu vse, co bude potreba pro >> zobrazeni >> >> Druha vec o ktere jsem premyslel a jsem rozhodnut ji udelat je >> pracovat s jednou sessionou, ale 2 ma transakcema. Tj. provedu zmeny a >> commitnu transakci, nasledne otevru dalsi v te same sessione, ale udelam ji >> read-only, aby se v ni nedaly delat zmeny a jenom se dotahavalo, pak vlastne >> nic nezamyka (mam to tak udela v DB diky spravnemu isolation >> levelu) a muze klidne trvat i par sekund. >> >> Jinak DTO neni navrhovy vzor ale obycejny workaround ... >> >> Jirka >> >>> Mam obecny problem s pouzivanim ORM frameworku u webovych aplikaci, >>> ktery se mi nedari uspokojive vyresit. Kdyz jsem si ted precetl clanek >>> Dagiho o DTO na java.cz a o tom, jak je to opomijeny vzor, pripomelo >>> mi to muj boj s DTO. >>> >>> Pouzivam Hibernate a puvodne jsem si (naivne) myslel, ze zivot bude >>> sladky, ze Hibernate domenove objekty budu vracet do view a to mi z nich >>> bude cist a zbavim se nutnosti psat DTO tridy. To jsem si myslel do doby, >>> nez jsem poprve uvidel vyjimky s hlaskou "Session is closed". Duvod vyjimky >>> je zcela pochopitelny, protoze Hibernate session (dale jen HS) mi managuje >>> JTA, takze ve view je session jiz uzavrena a kdyz se view pokousi dotahnout >>> nejakou lazy asociaci, vyhodi zminovanou vyjimku. >>> >>> Managovat HS v nejakem filtru ve view vrstve mi prijde nepouzitelne >>> pro vetsi aplikace s ohledem na to, ze view muze provadet dost dlouhe >>> akce, napriklad volat web-service, provadet nejaky casove slozitejsi >>> vypocet apod. Mangovani HS ve filtru (tzv. open-session-in-view >>> pattern) by tedy znamenalo: >>> >>> 1) HS a potazmo db spojeni budou alokovany na dlouhou dobu (sekundy >>> az >>> desitky sekund) -> vycerpani spojeni pri vetsi zatezi aplikace, >>> nektere stranky/akce view treba s db vubec nepracuji, tak proc >>> vytvaret HS a alokovat db spojeni >>> >>> 2) Pri otevreni HS bude db spojeni dlouho viset v necommitnutem stavu >>> (vlastne po celou dobu renderovani view) -> vyskyt locku/deadlocku v >>> db. >>> >>> Jak z toho ven? >>> >>> Momentalne resim tak, ze pro domenove objekty Hibernate pisu DTO >>> objekty a skripu zubama (dvakrat pisu to same, zmeny v domenovych >>> objektech se musi propagovat do DTO, nutnost rucne "presypavat" data >>> mezi domenovymi objekty a DTO). Zkratka z DTO patternu nejsem nijak >>> zvlast unesen, alespon ne v tomto kontextu. Napadlo me pouzivat 2 >>> session, ale to jsem nikde nevidel v akci a taky to nemam jeste uplne >>> promyslene: >>> >>> 1) lazy alokovana session, ktere je striktne read-only a je >>> managovana >>> ve view >>> 2) standardni "vykona" session managovana pres JTA >>> >>> Pak je potreba jen nejak automaticky zajistit (napr. pres nejaky JTA >>> interceptor), ze domenove objekty Hibernate predavane do view se sami >>> asociuji s tou read-only session a bude tedy mozne se vyhnout DTO >>> patternu pro praci s domenovymi daty a pomoci te read-only session >>> dotahovat i lazy asociace dle potreb view. > -- Jiří Mareš (mailto:[EMAIL PROTECTED]) ČSAD SVT Praha, s.r.o. (http://www.svt.cz) Czech Republic
