Mailing-List: contact users-help@deltaspike.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@deltaspike.apache.org
Received-SPF: pass (athena.apache.org: domain of rmpestano@gmail.com
 designates 209.85.192.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5531321D.8030006@gmail.com>
References: <5530D44D.4050603@senat.fr> <5531321D.8030006@gmail.com>
From: Rafael Pestano <rmpestano@gmail.com>
Date: Fri, 17 Apr 2015 13:30:06 -0300
Message-ID: 
 <CADjFuPqQfWnQ-6qTKwb0dmROz5Hi2bDjLTSWXTf7BW10zixmVA@mail.gmail.com>
Subject: Re: Extended EntityManager
To: users@deltaspike.apache.org
Content-Type: multipart/alternative; boundary=047d7b33d5bc0909980513ee1972

--047d7b33d5bc0909980513ee1972
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 seam=
2
> 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 ende=
d
> 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=C3=A9cup=C3=A8re=
 un...
>       if (em =3D=3D null) {
>          em =3D emf.createEntityManager();
>       }
>       return this.em;
>    }
>
>    @PreDestroy
>    public void terminer() {
>       if (em !=3D null) {
>          if (em.isOpen()) {
>             log.trace("close em {}", em);
>             em.close();
>          }
>       }
>       em =3D 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 =3D 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 d=
e
> CDI. +joinTransaction");
>          EntityManager em =3D 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 =3D Persistence.createEntityManagerFactory(<name of the PU here=
>);
>       em =3D 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 =C3=A9crit :
>
>> 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 busines=
s
>> logic but few users and a low load. I fully endorse the "entitymanager p=
er
>> 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=3DPersistenceContextType.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 pass=
ed
>> 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_persistenc=
e_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.
>> |
>>
>>
>


--=20
<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>

--047d7b33d5bc0909980513ee1972--