hi rafael, in that example you don't have an extended entity-manager and therefore the returned entity is detached. (as you can see in UserRepository the entity gets merged later on... - that's what mark mentioned in his first explanation as well.)
regards, gerhard 2015-04-20 17:05 GMT+02:00 Rafael Pestano <[email protected]>: > 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> >
