deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Extended EntityManager
Date Fri, 17 Apr 2015 17:57:40 GMT
I think it’s easier to make the class which contains the producer @AppliationScoped. That
should work well. Please note that injecting a @PersistenceUnit is fine but a @PersistenceContext
is _only_ allowed (as per spec) if you run ‚inside an EJB‘. 

LieGrue,
strub

> Am 17.04.2015 um 18:30 schrieb Rafael Pestano <rmpestano@gmail.com>:
> 
> Hi Denis,
> for situations where the scope is not active we use an interceptor to
> activate it, see this example:
> 
> http://gist.asciidoctor.org/?14312d475ab402768783
> 
> 
> 
> 2015-04-17 13:17 GMT-03:00 titou10 <titou10.titou10@gmail.com>:
> 
>> 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, l.penet@senat.fr 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>


Mime
View raw message