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>
