deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: Extended EntityManager
Date Tue, 21 Apr 2015 07:02:25 GMT
And here it comes:

Feedback and corrections are much appreciated!


> Am 20.04.2015 um 19:58 schrieb Mark Struberg <>:
> 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
> LieGrue,
> strub
>> Am 20.04.2015 um 17:14 schrieb Cody Lerum <>:
>> 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 <> 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 <>:
>>>> 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 <> wrote:
>>>>> Karl,
>>>>> Mostly because ConversationScope beans must be serializable and the EM
>>>>> 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
>>>>> 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
>>>>>> (about
>>>>>> 1k views) so I do need extended em.
>>>>>> cheers
>>>>>> On 19 April 2015 at 19:20, titou10 <>
>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>> 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
>>>> 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
>>>>>>>> Then I had bad luck - quite often ;)
>>>>>>>> And If you think this *may* happen within one conversation,
>>>>>>>> change
>>>>>>>>> the way redirects are send, or the way database is accessed
>>>>>>>>> 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
>>>>>>>> forbidden
>>>>>>>> by the JPA spec.
>>>>>>>> LieGrue,
>>>>>>>> strub
>>> --
>>> <>Att,
>>> Rafael M. Pestano
>>> Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
>>> @realpestano <>

View raw message