[ 
https://issues.apache.org/jira/browse/ARIES-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624706#comment-14624706
 ] 

Christian Schneider edited comment on ARIES-1346 at 7/13/15 2:27 PM:
---------------------------------------------------------------------

I just committed a change to use the Coordinator service in EmSupplier. The 
preCall and postCall methods are now creating and ending a coordination.

The EntityManager is now stored in the topmost Coordination. So you can achieve 
a coordinated series of calls to the DAO layer by using the Coordinator service 
to create your own Coordination around you calls.

Later we can remove the preCall and postCall methods and rely on a coordination 
to be created outside of EmSupplier. This would then have to be done in the 
JPATemplate as well as in the blueprint jpa module.

To make this even simpler I am thinking about using Coordination in aries 
transaction too. So coordinations would be managed together with the 
transactions. Additonally we could create a coordination for 
@Transactional(TxType.SUPPORTS) even when no real transaction is present. So 
you could just annotate your service method with this and automatically have 
coordinations.

Can you test the current trunk code and give some feedback?
As this is the first try in using the Coordinator I would like to get some 
feedback before doing a release if to see if we are on the right track.


was (Author: ch...@die-schneider.net):
I just committed a change to use the Coordinator service in EmSupplier. The 
preCall and postCall methods are now creating and ending a coordination.

The EntityManager is now stored in the topmost Coordination. So you can achieve 
a coordinated series of calls to the DAO layer by using the Coordinator service 
to create your own Coordination around you calls.

Later we can remove the preCall and postCall methods and rely on a coordination 
to be created outside of EmSupplier. This would then have to be done in the 
JPATemplate as well as in the blueprint jpa module.

To make this even simpler I am thinking about using Coordination in aries 
transaction too. So coordinations would be managed together with the 
transactions. Additonally we could create a coordination for 
@Transactional(TxType.SUPPORTS) even when no real transaction is present. So 
you could just annotate your service method with this and automatically have 
coordinations.

Can you test the current trunk code and give some feedback?
As this is the first try in using the Coordinator I would like to get some 
feedback before doing a release if we are on the right track.

> EntityManager should be reused for series of coordinated calls
> --------------------------------------------------------------
>
>                 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ś
>            Assignee: Christian Schneider
>            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)

Reply via email to