Mailing-List: contact users-help@deltaspike.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@deltaspike.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CADjFuPoTvwj3rDJ=6ThZxSpCn_xRNFVjWszH+0owAGZt85A7KQ@mail.gmail.com>
References: <5530D44D.4050603@senat.fr> <5531321D.8030006@gmail.com>
 <CADjFuPqQfWnQ-6qTKwb0dmROz5Hi2bDjLTSWXTf7BW10zixmVA@mail.gmail.com>
 <6B7D5343-207A-4D53-AB79-792AD861AB03@yahoo.de>
 <AC826C41-6210-47B7-9008-CBBC5E528621@senat.fr>
 <55316D67.4040907@gmail.com> <8F0948E9-B2DA-40B1-9480-57A3AAB16307@yahoo.de>
 <55324143.5090706@gmail.com> <E72FF466-A545-4F00-A67E-30EEA18B951F@yahoo.de>
 <5533A9B3.9010800@gmail.com> <23AF66EC-1CBF-4BDC-B4A6-3F6D89E97A5B@yahoo.de>
 <5533E3E5.8050707@gmail.com>
 <CAPCnv12xVGO7QCujg4+o1MFJSAfBjgmZom=D7NZYJDae=dZm+w@mail.gmail.com>
 <553401E7.5020207@gmail.com>
 <CAPCnv13yWrf-71Lxo5v10CqzqQ1Y-NGNvw+wS-EjaWNVs-xBJw@mail.gmail.com>
 <CADjFuPrmC1QmvJtkh=3Pn9tYFmqY+zLeNfb9PCOB8szkFqJ0fQ@mail.gmail.com>
 <0A62FAA4-6723-4524-8262-2BE6794B0AC5@yahoo.de>
 <CADjFuPoTvwj3rDJ=6ThZxSpCn_xRNFVjWszH+0owAGZt85A7KQ@mail.gmail.com>
From: Gerhard Petracek <gpetracek@apache.org>
Date: Mon, 20 Apr 2015 17:27:23 +0200
Message-ID: 
 <CAGJtJfE3a-0ujbda31Op3J61M0O0EjE-efw3LyNvKCoiJGu8Ag@mail.gmail.com>
Subject: Re: Extended EntityManager
To: users@deltaspike.apache.org
Content-Type: multipart/alternative; boundary=001a113d29da5271be05142992f4

--001a113d29da5271be05142992f4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 JP=
A
> 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 enti=
ty
> (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=E2=80=99t 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=E2=80=
=A6
> >
> > 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 ope=
n
> 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 O=
SI
> > > filter, doing extra queries for fetching always did the trick.
> > >
> > >
> > >
> > >
> > > 2015-04-19 18:19 GMT-03:00 Karl Kild=C3=A9n <karl.kilden@gmail.com>:
> > >
> > >> Thanks, feels obvious now when you said it. Off topic but for my app=
s
> > Marks
> > >> old suggestion on his blog to optionally drop pessimistic locking an=
d
> > 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 th=
e
> > >>> 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 n=
o
> > need
> > >>> to get the same EM. For this we use another layer (Check my previou=
s
> > >> posts
> > >>> about our the "EntityResolver" interface and implementations)
> > >>>
> > >>> Denis
> > >>>
> > >>>
> > >>> Le 2015-04-19 14:33, Karl Kild=C3=A9n a =C3=A9crit :
> > >>>
> > >>>> 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 a=
pp
> > >>>> (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 =C3=A9crit :
> > >>>>>
> > >>>>> Hi Dennis!
> > >>>>>>
> > >>>>>>
> > >>>>>>  Have you *ever* hit this situation?
> > >>>>>> Yes, under heavy load it happens pretty often actually (I=E2=80=
=99m
> 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
> > >> (=E2=80=9Aattached=E2=80=99)
> > >>>>>> 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 clie=
nt
> > >>>>> 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 =E2=80=9EsendRedirect" in the middle of a m=
ethod that
> > >> then
> > >>>>>
> > >>>>>> performs database access ..?
> > >>>>>>>
> > >>>>>>> You don=E2=80=99t 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=E2=80=A6
> > >>>>>> Then I had bad luck - quite often ;)
> > >>>>>>
> > >>>>>>
> > >>>>>>  And If you think this *may* happen within one conversation, the=
n
> > >>>>>> 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 =E2=80=9Eunfinished thread" is valid for AN=
Y
> > >>>>>>
> > >>>>>>> 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=E2=80=99s e=
xplicitly
> > >>>>>> 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 Su=
l
> > > 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>
>

--001a113d29da5271be05142992f4--