You can do the same with DeltaSpike @Transactional and @TransactionScoped EntityManagers ;)
The difference is subtle but very important. Imo the EE7 javax.transaction.Transactional is as broken as EJB transactions if you build big real world apps (banks, insurance companies, government projects, etc). I really dislike the Exception handling in EJB and EE7 @Transactional. It’s soooo weird and most people are not aware how it works. I probably really should write up another blog post. LieGrue, strub > Am 20.04.2015 um 17:14 schrieb Cody Lerum <[email protected]>: > > 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>
