[
https://issues.apache.org/jira/browse/ARIES-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14615132#comment-14615132
]
Christian Schneider edited comment on ARIES-1346 at 7/6/15 2:59 PM:
--------------------------------------------------------------------
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. The reason why I currently close
the EntityManager when on the outermost postCall was to make sure that we have
no dangling EntityManager instances like in previous Aries JPA versions. This
caused problems when the EntityManagerFactory was to be shut down.
About two weeks ago I discussed with Peter Kriens how to handle the
EntityManager lifecycle and transactional contexts. He proposed to use the OSGi
coordination API for this task (See
https://osgi.org/javadoc/r5/enterprise/org/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 Coordination
as a Participant. This would allow to then close the EntityManager when the
Coordination ends without directly tying it to the Transaction.
What do you think?
was (Author: ch...@die-schneider.net):
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
EntityManager lifecycle and transactional contexts. He proposed to use the OSGi
coordination API for this task (See
https://osgi.org/javadoc/r5/enterprise/org/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 Coordination
as a Participant. This would allow to then close the EntityManager when the
Coordination ends without directly tying it to the Transaction.
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ł Woś
> Priority: Critical
>
> Consider scenario:
> - blueprint service A with JPA
> {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 transaction
> {code}
> B {
> @Transaction
> B1() {
> C = 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 one.
> Entity C is managed within first EM but not the second.
> EM should be shared in transaction within single Thread, not by single method
> 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 database
> (different unit name)
> - bundle B1,B2,B3 with rest services using entity services in a transaction
> (Separation of domain logic from business logic). Each of B1,B2,B3 can use
> any method of A1,A2,A3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
