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
