deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cody Lerum <cody.le...@gmail.com>
Subject Re: Extended EntityManager
Date Mon, 20 Apr 2015 15:14:08 GMT
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>

Mime
View raw message