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
