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>
