Mark,
We keep the EM in the conversation scope, but we expose it at the request scope
A new EM is created only when there is no one currently in the conversation scope, so we have the same EM for the duration of the
conversation, short or long:
It is very close to what Seam 2 did
@ConversationScoped
public class EntityManagerProducer {
=====> private transient EntityManager em;
@PersistenceUnit
private EntityManagerFactory emf;
@Produces
@RequestScoped
protected EntityManager creerEntityManager() {
======> if (em == null) {
======> em = emf.createEntityManager();
======> }
======> return this.em;
}
Le 2015-04-18 01:35, Mark Struberg a écrit :
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
