Zdravim, 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.
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. 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. Honza -----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 Ahoj, 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])
