FWIW I started developing my application on Seam 2 with it's Conversation scoped EntityManager. Everything was so simple and everything worked, but my application was also very small at the time and everything was invoked by a user clicking a button or a link in a JSF page.
Over time my application grew to have JAX-WS and JAX-RS and timers. It also migrated from Seam to EE6/CDI. Since there are no Conversations during these types of requests this created issues and hacky workarounds. Eventually I converted to a RequestScoped EntityManager and everything was simple except for lazy loading and merging. Over more time my application started to pick up some batch type processing requirements where I wanted to operate on multiple transactions within a single request which may be invoked from many different places. I migrated to EE7 and converted to a EM per transaction. It is a bit more work to ensure that you merge and trigger lazy loads, but I feel that it gives me a lot of flexibility and removes a lot of limitations. In my experience the extended EntityManagers can be a great time savings in initial app development, but they are also potential long term technical debt if your application keeps growing and introducing new requirements. I would just recommend that you really understand the context you are using (Session, Conversation, Request, Transaction) and know about when these contexts are and aren't created (and destroyed). -C On Sun, Apr 19, 2015 at 9:46 PM, Rafael Pestano <[email protected]> wrote: > 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>
