aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré>
Subject RE: [Discuss] Releases of org.apache.aries.transaction.blueprint and jpa next week
Date Tue, 28 Jul 2015 10:28:38 GMT


Sent from my Samsung device

-------- Original message --------
From: Christian Schneider <> 
Date: 28/07/2015  12:00  (GMT+01:00) 
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:

and these for Aries transaction blueprint 1.1.0:

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 Schneider

Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message