deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gpetra...@apache.org>
Subject Re: Extended EntityManager
Date Mon, 20 Apr 2015 15:27:23 GMT
hi rafael,

in that example you don't have an extended entity-manager and therefore the
returned entity is detached.
(as you can see in UserRepository the entity gets merged later on... -
that's what mark mentioned in his first explanation as well.)

regards,
gerhard



2015-04-20 17:05 GMT+02:00 Rafael Pestano <rmpestano@gmail.com>:

> Hi Mark,
>
> we don't use DTOs, our JSF forms(backed by ViewAccessScoped beans) use JPA
> entities and we usually load dependent entities on preRenderView event or
> on demand (click on button, fetch relationships and go to detail page)
>
> Do you have a sample where DTO is needed when using a stateless entity
> manager?
>
> eg: at [1] UserService uses a transaction entity manager and the JPA entity
> (User) is expoded direcly in the JSF form. But of course in this example
> user is a simple entity but if it were a complex one I think it would not
> be necessary to have a User DTO.
>
>
>
> [1]
>
> https://github.com/os890/ee6-ds-demo/blob/master/src/main/java/org/os890/demo/ee6/ds/view/controller/user/RegistrationPage.java
>
>
> 2015-04-20 11:44 GMT-03:00 Mark Struberg <struberg@yahoo.de>:
>
> > If your app doesn’t store entities in JSF backing beans but use DTOs then
> > all is fine.
> > But does your DTOs contain the @Version field of your entity? Do you
> > manually check if the version is still unchanged on the re-apply?
> > Most of the applications working with DTOs did _not_ do that and are
> utter
> > broken because they overwrite state in the db without any locking…
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 20.04.2015 um 03:46 schrieb Rafael Pestano <rmpestano@gmail.com>:
> > >
> > > 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