I guess we have a slightly different picture of what we do. A Conversation per definition is a part of a Session. A Http Session can contain multiple CDI Conversations. But a CDI Conversation can NEVER span HttpSessions of different users. So each user always has a different Conversation. Are we d’accord so far?
And no, I don’t have this often, but it _does_ happen. And you don’t even need Ajax for it. It works with simply redirects to another JSF page. > 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)? This is precisely what _sometimes_ (again, not often) happens. The point is that the new request (the redirected one) gets served by a different thread while the original thread still needs to finish his work. It will not often happen if you use DTOs but you might get this case more often if you store entities directly in your conversation (Another symptom of the same underlying problem). LieGrue, strub > Am 19.04.2015 um 19:20 schrieb titou10 <[email protected]>: > > > > 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 >
