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 Tue, 21 Apr 2015 07:02:25 GMT
And here it comes:

https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/

Feedback and corrections are much appreciated!

LieGrue,
strub


> Am 20.04.2015 um 19:58 schrieb Mark Struberg <struberg@yahoo.de>:
> 
> 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
post.
> 
> LieGrue,
> strub
> 
>> Am 20.04.2015 um 17:14 schrieb Cody Lerum <cody.lerum@gmail.com>:
>> 
>> 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