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 <[email protected]> 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 <[email protected]> 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 >>>> >>>> >>> >
