aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <>
Subject [jira] [Resolved] (ARIES-1346) EntityManager should be reused for series of coordinated calls
Date Mon, 13 Jul 2015 14:28:04 GMT


Christian Schneider resolved ARIES-1346.
    Resolution: Fixed

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:
>             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

View raw message