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

Reply via email to