2015-04-17 13:17 GMT-03:00 titou10 <[email protected]>: > Ludovic, > 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 > > @ConversationScoped > public class EntityManagerProducer { > private transient EntityManager em; > > @PersistenceUnit > private EntityManagerFactory emf; > > @Produces > @RequestScoped > 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; > } > > @PreDestroy > public void terminer() { > if (em != null) { > if (em.isOpen()) { > log.trace("close em {}", em); > em.close(); > } > } > 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 contexts: > - online/web in EJB3 SFSB,SLSB > - online in MDB or Web Services beans (No conversationscope here, but > @PersistenceUnit IS available) > - 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: > @Stateless > public class EntityManagerResolverOnline implements EntityManagerResolver { > @PersistenceContext > private EntityManager emFromEJB; > > @Inject > 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(); > em.joinTransaction(); > 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: > @Alternative > @ApplicationScoped > public class EntityManagerBatchResolver implements EntityManagerResolver { > > private EntityManagerFactory emf; > private EntityManager em; > > @PostConstruct > public void initialiser() { > log.debug("@PostConstruct. Utilisation de > EntityManagerBatchResolver"); > emf = Persistence.createEntityManagerFactory(<name of the PU here>); > em = emf.createEntityManager(); > } > > @PreDestroy > public void terminer() { > log.debug("@PreDestroy. terminer"); > emf.close(); > } > > 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.. > > Denis > > > Le 2015-04-17 05:37, [email protected] 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. >> >> https://developer.jboss.org/wiki/OpenSessionInView >> >> 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 ;-) ) >> https://struberg.wordpress.com/2012/04/25/is-there-a-way-to-fix-the-jpa-entitymanager/ >> , 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 >> >> >> http://deltaspike.apache.org/documentation/jpa.html#_extended_persistence_contexts >> >> 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 >> >> >> | >> | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. >> | >> >> >
-- <http://www.advancedit.com.br/>Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul http://rpestano.wordpress.com/ @realpestano <https://twitter.com/realpestano>
