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