Hi MuthuKumar On 28.09.2011 17:52, MuthuKumar Laxman wrote: > Hi Yun/Michael, > > > > We are using DAY CQ5 CMS tool.
Nice to hear ;-) > 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. I fear this is the wrong forum to post this question. Please contact Adobe support or try day-communi...@googlegroups.com Regards Felix > > > > > > *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 _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
