deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From titou10 <>
Subject Re: Extended EntityManager
Date Fri, 17 Apr 2015 16:17:33 GMT
I don't know if it may be of some help for you, but we have a lot of seam2 apps that we migrated
to CDI and we had to face the 
problems you describe (With many other..)
We tried first to use CODI then DeltaSpike, in its early days but we ended to create our own
CDIUtils libs..
To solve the problem, we exposed the EM in RequestScoped but it is kept internally a ConversationScoped
Bean holder:
So when a LRC is on, we always get the same EM

public class EntityManagerProducer {
    private transient EntityManager em;

    private EntityManagerFactory    emf;

    protected EntityManager creerEntityManager() {
       // On n'a pas de EM en scope conversation, on en récupère un...
       if (em == null) {
          em = emf.createEntityManager();
       return this.em;

    public void terminer() {
       if (em != null) {
          if (em.isOpen()) {
             log.trace("close em {}", em);
       em = null;

Also the EM is not directly injected into Beans as our "Business Objects" are held in a jar
and the jar may be used in 3 different 
- online/web in EJB3 SFSB,SLSB
- online in MDB or Web Services beans (No conversationscope here, but @PersistenceUnit IS
- in batchs/JUnit (No conversationscope here, and no@PersistenceUnit available from J2SE)

We have an interface called "EMResolver" that is injected in BO beans:
public interface EntityManagerResolver {
    EntityManager getEm();

with 2 different implentations, one onlie, one for batchs (that is declared as an @Alternative)
The online implementation is:
public class EntityManagerResolverOnline implements EntityManagerResolver {
    private EntityManager           emFromEJB;

    private Instance<EntityManager> emLazyInstance;

    public EntityManager getEm() {
       Boolean estMDBouWS = ThreadLocalContextHolder.isMDBorWS();
       if (estMDBouWS) {
          log.trace("Contexte online MDB ou WS - EntityManager vient de @PersistenceContext.");
          return emFromEJB;
       } else {
          log.trace("Contexte online non MDB ni WS - EntityManager vient de CDI. +joinTransaction");
          EntityManager em = emLazyInstance.get();
          return em;
The ThreadLocalContextHolder keep a boolean "threadlocal" variable set by MDBs (from MDB own
superclass) or WS (JAX-WS own handler)

The batch implementation:
public class EntityManagerBatchResolver implements EntityManagerResolver {

    private EntityManagerFactory emf;
    private EntityManager        em;

    public void initialiser() {
       log.debug("@PostConstruct. Utilisation de EntityManagerBatchResolver");
       emf = Persistence.createEntityManagerFactory(<name of the PU here>);
       em = emf.createEntityManager();

    public void terminer() {
       log.debug("@PreDestroy. terminer");

    public EntityManager getEm() {
       return em;

Maybe it is not very academic but it works perfectly well for us and made our move from seam
2 smotth..

Hope this helps..


Le 2015-04-17 05:37, a écrit :
> Dear all,
> I am actually trying to switch from "raw" Hibernate to JPA.
> I have the typical "keep the same entitymanager" during a scenario problem. IMHO, merging
huge collections of entities is a 
> nightmare that is not worth the cost when you deal with applications with a lot of business
logic but few users and a low load. I 
> fully endorse the "entitymanager per request" pattern for application having high trafic,
and so need to be stateless, replicated, 
> etc. but it does not appear to me to be the magic solution to all problems.
> With hibernate, I historically solved it with the "open session in view" pattern. It
is ugly when evaluated according to actual 
> standards, but it works.
> When I tried to find the equivalent for JPA, I basically found
> @PersistenceContext(type=PersistenceContextType.EXTENDED)
> ...which could be a fit if I was using container managed datasources
> When digging the Hibernate 4.3.8 jpa implementation, I noticed that when I use application
managed EntityManager-s, they are all 
> created with PersistenceContextType.EXTENDED, and that this attribute is finally passed
to :
> AbstractEntityManagerImpl base class constructor :
>     protected AbstractEntityManagerImpl(
>             EntityManagerFactoryImpl entityManagerFactory,
>             PersistenceContextType type,  // TODO:  remove as no longer used
>             SynchronizationType synchronizationType,
> and is just ignored. :-)
> On this blog (I like good authors ;-) )
, I 
> found mention of Avaje, which could be a fit if it was more of a standard.
> I also fond on the net references to CODI, MyFaces Orchestra and Seam solutions to this
problem. Most of the type it was also 
> indicated that Deltaspike is "the way to go". An affirmation that is clearly also mine
in general.
> However, I did not find a ready-to-use solution in the doc
> I was a bit surprised, as some people stated that Seam code was to be merged in Deltaspike
not to find a turn key solution.
> Did I miss / misunderstood something ?
> This is not a blocking problem to me. I can just use plain hibernate or unwrapped jpa/hibernate
sessions and it will work... But I 
> would like to understand. :-)
> Thanks in advance,
> Ludovic
> |
> |

View raw message