Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Date: Mon, 6 Jul 2015 14:58:04 +0000 (UTC)
From: "Christian Schneider (JIRA)" <jira@apache.org>
To: dev@aries.apache.org
Message-ID: <JIRA.12842850.1436177198000.106026.1436194684670@Atlassian.JIRA>
In-Reply-To: <JIRA.12842850.1436177198000@Atlassian.JIRA>
References: <JIRA.12842850.1436177198000@Atlassian.JIRA>
 <JIRA.12842850.1436177198447@arcas>
Subject: [jira] [Commented] (ARIES-1346) EntityManager injection issue
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/ARIES-1346?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1461=
5132#comment-14615132 ]=20

Christian Schneider commented on ARIES-1346:
--------------------------------------------

I agree that this is a typical use case and we should support it. I am not =
sure though how to implement it in the best way.
About two weeks ago I discussed with Peter Kriens how to handle the EntityM=
anager lifecycle and transactional contexts. He proposed to use the OSGi co=
ordination API for this task (See https://osgi.org/javadoc/r5/enterprise/or=
g/osgi/service/coordinator/Coordination.html).

I think it could indeed help. The concept would be to start a Coordination =
where the transaction starts and attach the EntityManager to the Coordinati=
on as a Participant. This would allow to then close the EntityManager when =
the Coordination ends without directly tying it to the Transaction.=20
What do you think?


> EntityManager injection issue
> -----------------------------
>
>                 Key: ARIES-1346
>                 URL: https://issues.apache.org/jira/browse/ARIES-1346
>             Project: Aries
>          Issue Type: Improvement
>          Components: JPA
>    Affects Versions: jpa-2.0.0
>         Environment: karaf-4.0.0, java 8
>            Reporter: Micha=C5=82 Wo=C5=9B
>            Priority: Critical
>
> Consider scenario:
> - blueprint service A with JPA=20
> {code}
>    A {
>       C find() {
>          return em.find();
>       }
>       void delete(C c) {
>          em.remove(c)
>       }
>   }
> {code}
> - blueprint  bean B with A injected. B call methods of A within transacti=
on
> {code}
> B {
>    @Transaction
>    B1() {
>       C =3D A.find(); // Entity returned by find (em.find())
>       A.delete(C); // Entity is not attached!!!!!!
>    }
> }
> {code}
> Reason:
> Method of bean A are proxied in following way:
> {code}
> emsupplier.precall()
> emsupplier.get()
> find(); //or delete()
> emsupplier.postcall()
> {code}
> Each method call gets its own EM so find has one EM, delete has another o=
ne. Entity C is managed within first EM but not the second.
> EM should be shared in transaction within single Thread, not by single me=
thod call.
> Please also note that:
> - transaction could be JTA and use different units in single transaction
> My scenario:
> - bundle A1,A2,A3 with persistence JPA exposing entities through services=
 (domain module), Each bundle (A1, A2, A3) uses different schema in databas=
e (different unit name)
> - bundle B1,B2,B3 with rest  services using entity services in a transact=
ion
> (Separation of domain logic from business logic). Each of B1,B2,B3 can us=
e any method of A1,A2,A3


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)