Hi Mark, we don't use DTOs, our JSF forms(backed by ViewAccessScoped beans) use JPA entities and we usually load dependent entities on preRenderView event or on demand (click on button, fetch relationships and go to detail page)
Do you have a sample where DTO is needed when using a stateless entity manager? eg: at [1] UserService uses a transaction entity manager and the JPA entity (User) is expoded direcly in the JSF form. But of course in this example user is a simple entity but if it were a complex one I think it would not be necessary to have a User DTO. [1] https://github.com/os890/ee6-ds-demo/blob/master/src/main/java/org/os890/demo/ee6/ds/view/controller/user/RegistrationPage.java 2015-04-20 11:44 GMT-03:00 Mark Struberg <[email protected]>: > If your app doesn’t store entities in JSF backing beans but use DTOs then > all is fine. > But does your DTOs contain the @Version field of your entity? Do you > manually check if the version is still unchanged on the re-apply? > Most of the applications working with DTOs did _not_ do that and are utter > broken because they overwrite state in the db without any locking… > > LieGrue, > strub > > > > Am 20.04.2015 um 03:46 schrieb Rafael Pestano <[email protected]>: > > > > reading this topic gives me the sensation that there are more "cons" then > > "pros" when using an extended entity manager. > > > > Besides avoiding Lazy initialization exceptions by letting the EM open in > > eg master detail views where else going stateful is really advantageous? > > > > I've been working with stateless EM quite a lot and never needed an OSI > > filter, doing extra queries for fetching always did the trick. > > > > > > > > > > 2015-04-19 18:19 GMT-03:00 Karl Kildén <[email protected]>: > > > >> Thanks, feels obvious now when you said it. Off topic but for my apps > Marks > >> old suggestion on his blog to optionally drop pessimistic locking and > make > >> it Serializable would be perfect for my apps. > >> > >> > >> > >> > >> > >> On 19 April 2015 at 21:28, titou10 <[email protected]> wrote: > >> > >>> Karl, > >>> > >>> Mostly because ConversationScope beans must be serializable and the EM > is > >>> not (check the "transient" keyword on the variable that keeps in the > >>> ConversationScope Holder) and the fact that in our web apps, the EM can > >> be > >>> injected in components where the ConversationScope is not active > (Namely > >>> MDBs and JAX-WS endpoints), where there is only one "request" and no > need > >>> to get the same EM. For this we use another layer (Check my previous > >> posts > >>> about our the "EntityResolver" interface and implementations) > >>> > >>> Denis > >>> > >>> > >>> Le 2015-04-19 14:33, Karl Kildén a écrit : > >>> > >>>> Denis, > >>>> > >>>> What's the added benefit of wrapping the em in @ConversationScoped > >> instead > >>>> of exposing it like this directly. I am also porting a huge seam app > >>>> (about > >>>> 1k views) so I do need extended em. > >>>> > >>>> cheers > >>>> > >>>> On 19 April 2015 at 19:20, titou10 <[email protected]> wrote: > >>>> > >>>> > >>>>> Le 2015-04-19 11:24, Mark Struberg a écrit : > >>>>> > >>>>> Hi Dennis! > >>>>>> > >>>>>> > >>>>>> Have you *ever* hit this situation? > >>>>>> Yes, under heavy load it happens pretty often actually (I’m talking > >>>>>> about > >>>>>> multi-million request/day public internet apps). It also depends a > bit > >>>>>> on > >>>>>> the JPA container you use. From the pure spec it is forbitten to > touch > >>>>>> the > >>>>>> EntityManager in parallel threads and also to touch managed > >> (‚attached’) > >>>>>> entities in parallel threads. What JPA container are you using? > >>>>>> > >>>>>> Here we are talking about one ONE EM per ONE CDI Conversation. > >>>>> So you have applications with multi-million request/day concurrently > >> in > >>>>> one CDI Conversation that may lead *often* to a misuse of the EM ? > >>>>> Impressive... How do you do that: Ajax requests? Proprietary client > >>>>> javascript framework? > >>>>> Or you are talking about *not closed EM* because the @PreDestroy > >> callback > >>>>> method has not been called in some particulat situation (sendRedirect > >> is > >>>>> called and the new request is processed before the initial request)? > >>>>> Sorry, Mark but you lost me..... > >>>>> Denis > >>>>> > >>>>> > >>>>> Also, who programs a „sendRedirect" in the middle of a method that > >> then > >>>>> > >>>>>> performs database access ..? > >>>>>>> > >>>>>>> You don’t need to do database access even. It is enough that the > >>>>>> entitymanager is not closed as per the spec. > >>>>>> > >>>>>> > >>>>>> Even so, this is pure theory, the chance are so tiny this happens… > >>>>>> Then I had bad luck - quite often ;) > >>>>>> > >>>>>> > >>>>>> And If you think this *may* happen within one conversation, then > >>>>>> change > >>>>>> > >>>>>>> the way redirects are send, or the way database is accessed in > >>>>>>> parallel in > >>>>>>> Ajax requests. not the way EM is used IMHO > >>>>>>> > >>>>>>> That might be a solution. Or force the EM to get closed before the > >>>>>> redirect. > >>>>>> > >>>>>> Also your remark on „unfinished thread" is valid for ANY > >>>>>> > >>>>>>> components/resources held in ConversationScope, not just the EM, > >> true? > >>>>>>> > >>>>>>> Yes, but most components have no problems with getting accessed in > >>>>>> parallel. For managed Entities and EntityManagers it’s explicitly > >>>>>> forbidden > >>>>>> by the JPA spec. > >>>>>> > >>>>>> LieGrue, > >>>>>> strub > >>>>>> > >>>>>> > >>>>> > >>> > >> > > > > > > > > -- > > <http://www.advancedit.com.br/>Att, > > > > Rafael M. Pestano > > > > Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul > > http://rpestano.wordpress.com/ > > @realpestano <https://twitter.com/realpestano> > > -- <http://www.advancedit.com.br/>Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul http://rpestano.wordpress.com/ @realpestano <https://twitter.com/realpestano>
