But in your example only the bean ‚holding‘ the producer method is @ConversationScoped. The EntityManager you create is only @RequestScoped (which is good imo!), right? So the lifecycle of the EM will effectively be 1-per-prequest.
LieGrue, strub > Am 17.04.2015 um 22:30 schrieb titou10 <[email protected]>: > > I can't comment on the DS/JPA example, but that's why the solution we use > keeps the EM instance in a variable, variable held in the @ConversationScoped > Bean that "contains" the producer that "exposes" this EM in the @RequestScope > The EM is opened/closed only on conversation boundaries (short or long) , > very similar to what Seam 2 does (In CDI, Conversations length is not > exactly the same as in Seam Conversations) > Denis > > Le 2015-04-17 16:05, Ludovic Pénet a écrit : >> Thanks to everybody for your valuable adviced. >> >> I ended with an @ApplicationScoped EntityManagerProducer, producing >> @ViewAccessScoped ExtendedEntityManager. >> ExtendedEntityManager is identical to DS JPA example. >> >> So, something very close from DS JPA page example. >> >> http://deltaspike.apache.org/documentation/jpa.html#_extended_persistence_contexts >> >> In fact, I am still a bit puzzled by DS JPA example, because the >> EntityManager it produces is @RequestScoped. >> >> So, when I basically copied/pasted it, the EM was just opened and closed on >> every request. And, for an example, session was closed when some hibernate >> proxies were accessed during serialization... >> >> Do I miss something obvious, or should the doc rather mention that one >> should use a scope such as @ViewScoped, @SessionScoped or @ViewAccessScoped >> rather than @RequestScoped ? >> >> Ludovic >> >> >
