And here it comes: https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
Feedback and corrections are much appreciated! LieGrue, strub > Am 20.04.2015 um 19:58 schrieb Mark Struberg <[email protected]>: > > 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> >
