Hi Yun/Michael,
We are using DAY CQ5 CMS tool. We have a requirement in which we need to expose
few OSGI services to another application. For that we wrote a JAX-WS web
service as OSGI bundle but something is going wrong in between and it’s
throwing Stackoverflow exception. Please help me resolve this and host a web
service in OSGI/DAY CQ5.
From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] On
Behalf Of Mike Keith
Sent: Wednesday, September 28, 2011 7:58 PM
To: yun.d...@icw.de
Cc: osgi-dev@mail.osgi.org
Subject: Re: [osgi-dev] Cross-bundle transactions with OSGi JPA and JTA
Hi Yun,
I have made some comments inline to hopefully help you with your questions.
Regards,
-Mike
From: yun.d...@icw.de<mailto:yun.d...@icw.de>
Subject: [osgi-dev] Cross-bundle transactions with OSGi JPA and JTA
Date: 27 september 2011 05:01:39 GMT+02:00
To: osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>
Reply-To: OSGi Developer Mail List
<osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>>
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<mailto:yun.d...@icw.de> | www.icw.de<http://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<mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are
not
to copy, disclose, or distribute this e-mail or its contents to any other
person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has
taken
every reasonable precaution to minimize this risk, but is not liable for any
damage
you may sustain as a result of any virus in this e-mail. You should carry out
your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this
e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev