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>
