+1 (non binding) regards Giuseppe
2015-07-28 12:28 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: > > > +1 > RegardsJB > > > Sent from my Samsung device > > -------- Original message -------- > From: Christian Schneider <[email protected]> > Date: 28/07/2015 12:00 (GMT+01:00) > To: [email protected] > Subject: [Discuss] Releases of org.apache.aries.transaction.blueprint and > jpa next week > > I plan to do releases of org.apache.aries.transaction.blueprint and jpa > next week. Till then there is still some time so I would appreciate > feedback about the new design decisions listed below. As long as we do > not have a release they can still be changed. > > These are the issues for Aries JPA 2.1.0: > > https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20jpa-2.1.0%20AND%20project%20%3D%20ARIES > > and these for Aries transaction blueprint 1.1.0: > > https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20transaction-blueprint-1.1.0%20AND%20project%20%3D%20ARIES > > The main improvements are: > > 1) Support for JTA 1.2 @Transactional annotations. This will make user > code independent of the Aries transaction API > 2) Support for Coordinations using OSGi Coordinator service. > In JPA 2.0.0 the lifecycle of the EntityManager was defined by the > outermost bean with a @PersistenceContext injection. > This is not very suitable if you want to span several DAO calls but do > this from a class outside the persistence layer. In Aries JPA 2.1.0. The > lifecycle of EntityManager is defined by the outermost Coordination of > the thread. > 3) For each persistence unit there is now also an EntityManager service > published. Together with the Coordination support this allows to inject > the EntityManager into > DS components as this approach does not require an interceptor. The user > has to make sure though that such components are always called with an > active Coordination > 3) Support for coordinations declared using @Transactional. Each method > annotated with @Transactional will open and close a coordination. So by > default the EntityManager lifecycle will now include the outermost > transaction. Coordinations are also created for TxType.SUPPORTS. So this > allows to define boundaries for the EntityManager lifecycle without > requiring a real transaction. > 4) JPA annotions can now also be defined on parent classes > > I am also thinking of supporting transactions using a template mechanism > like JPATemplate but without the dependency on an EntityManager. So it > can be used outside the persistence layer. This could then also be used > to trigger coordinations like for the annotation case. Any thoughts > about this? > > The EmSupplier preCall and postCall methods now simply begin and end a > coordination. So they are not strictly needed anymore. So I am thinking > about deprecating these methods or even the whole EmSupplier interface > and remove it in the next major release. If at this point Java 8 is the > minimum requirement we can replace EmSupplier with > Supplier<EntityManager>. This would then make the user independent of > our Aries JPA API. This is not planned for the near term but I would > already be happy about some feedback about it. One concern I have is how > to identify such a generic service as the interface will be just > Supplier at runtime. > > Best regards > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
