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])
