deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Extended EntityManager
Date Mon, 20 Apr 2015 14:44:01 GMT
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>


Mime
View raw message