Hi! It’s not technically broken IF you know what you do. What I tried to emphase is that it is really hard to get right for people who are not that deep into that stuff like we are. I’ve seen this handled correctly in 3 out of 10 projects. Means 7 out of 10 projects are having troubles in their error handling chains or potentially creating inconsistent data.
LieGrue, strub > Am 21.04.2015 um 13:07 schrieb Rafael Pestano <[email protected]>: > > Hi Mark, > > i don't think it's broken but i agree with CODI/DS transaction management > superiority, in fact i've using it for years on my personal projects > <https://github.com/rmpestano/jsf-issuetracker-project/blob/master/src/br/com/triadworks/issuetracker/dao/impl/IssueDaoImpl.java> > but use EJBs on my company and don't think its broken, even for high load > application. > > Congrats for the post. > > > 2015-04-21 4:02 GMT-03:00 Mark Struberg <[email protected]>: > >> 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> >>> >> >> > > > -- > <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>
