deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Pestano <rmpest...@gmail.com>
Subject Re: Extended EntityManager
Date Tue, 21 Apr 2015 11:07:00 GMT
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 <struberg@yahoo.de>:

> 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 <struberg@yahoo.de>:
> >
> > 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 <cody.lerum@gmail.com>:
> >>
> >> 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 <rmpestano@gmail.com>
> 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 <karl.kilden@gmail.com>:
> >>>
> >>>> 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 <titou10.titou10@gmail.com>
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 <titou10.titou10@gmail.com>
> 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>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message