Hi Yun,
I have made some comments inline to hopefully help you with your
questions.
Regards,
-Mike
Subject: [osgi-dev]
Cross-bundle transactions with OSGi JPA and JTA
Date: 27
september 2011 05:01:39 GMT+02:00
Hi All,
I have a question about how cross bundle transactions are
handled with
OSGi JPA and JTA. I read the JPA and JTA service specification
in OSGi
Enterprise Specification 4.2 and browsed in the source code of
Apache
Aries.
With OSGi JPA Service, each Persistent Bundle provides its own
entity
classes and a persistence context (e.g. in persistence.xml).
For each
persistence unit, the JPA provider registers an Entity Manager
Factory
(Builder) service, which can be retrieved as a service by a
Client Bundle
to save or retrieve objects in the Persistent Bundle.
My Question is concerned with cross-bundle transactions, i.e.,
transactions which span serveral Persistent Bundles. In
particular, I am
interested in these transactions, where the persistent bundles
share the
same datasource. This is a typical situation in enterprise
applications. I
assume, due to the introduction of multiple Entity Managers,
multiple
sessions will be opened for a cross-bundle transaction. Is it
correct? To
Actually, it is not common that multiple persistence units write to
the same
datasource, but in large integration systems I do see operations
that span
multiple persistence units to different datasources. Either way,
though, the
"cross-bundle transaction" is in play.
ensure atomicity of a cross-bundle transaction with a shared
datasource,
the sessions opened by each involved Persistent Bundle must be
synchronized, e.g. by sharing the same database connection.
There are three points to make, here:
1) Within the JTA transaction it is the job of the transactional
Resource (in this
case the XA datasource impl by the driver) to ensure that any
underlying
transaction-specific resources used within it (in this case a
transactional
JDBC connection) end up being shared/used within the same
transactional
context.
2) In order for the operations on the different persistence units to
be enlisted in
the same transaction then they must be configured to use
transactional datasources
(whether they be the same or different datasources they must be
transactional, i.e. XA).
3) The OSGi JPA specification does not define the use of datasources
(transactional
or otherwise). Aries supports them, but it is beyond what the spec
defines, so Aries may
choose to implement it any way it likes.
As far as I understand OSGi JTA transaction service
specification, it
focuses on distributed transactions which use two-phase commit
(TPC) to
ensure atomicity. Although a TPC can be used to synchronize
cross-bundle
transactions described above, it seems to me that it is
unnecessarily
complex and expensive when considering that the transaction is
actually
backed by the same datasource.
The OSGi JTA spec does not go into specific detail about how XA
Resources
are managed by the JTA Provider. This is left to the transaction
implementation,
and every one that I have ever seen that is any good at all
optimizes the case
when only one resource has been enlisted. In other words, in
practice, 2PC gets
reduced to a local protocol.
I looked at the source code of
org.apache.aries.transaction.GeronimoPlatformTransactionManager
in the
Apache Aries project. Internally,
GeronimoPlatformTransactionManager uses
Spring's JtaTransactionManager. So I got the impression that
Apache Aries
is handling all cross-bundle transactions with a two-phase
commit process.
Do I understand correctly?
I am not sure what Aries/Geronimo does, but the Spring
JtaTransactionManager
is just an abstraction over an underlying transaction manager, it is
not actually a
transaction manager implementation. There must be some layer plugged
into it that
does the real work of implementing transactions. That is where the
optimization
generally happens.
If you have any specific questions about the Aries implementation
you should really
be raising them on the Aries forum, though. Folks there will be able
to give you answers
relating to the features in their product that are not defined by
the OSGi specifications.
Best regards,
Yun
Dr. Yun Ding | Software Architect | Development & Delivery
InterComponentWare AG | Altrottstraße 31 | 69190 Walldorf
(Baden) |
Germany
yun.d...@icw.de
| www.icw.de
InterComponentWare AG:
Vorstand: Peter Kirschbauer (Vors.), Jörg Stadler
Aufsichtsratsvors.: Prof. Dr. Christof Hettich
Firmensitz: 69190 Walldorf, Altrottstraße 31
AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
|
