Hi Gerhard, yea, thats what i said "UserService uses a transaction entity manager"
so that's my point, on that example although the entity is detached we don't need DTOs right? we just have "more work" to reatach it...anyway @Cody Lerum <https://plus.google.com/u/0/102516208312961178993?prsrc=4> gave us a great explanation/report thanks for the great discussion. 2015-04-20 12:27 GMT-03:00 Gerhard Petracek <[email protected]>: > 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> > > > -- <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>
