Hello Great work, I'll try to look and play with it.
regards Grzegorz Grzybek 2017-07-06 16:48 GMT+02:00 Guillaume Nodet <[email protected]>: > Fwiw, I just pushed to https://github.com/gnodet/org.ops4j.pax.transx a > transaction api + 3 implementation bundles for Geronimo, Narayana and > Atomikos. > The API is designed to support Last-Resource-Commit (supported by Geronimo > and Narayana) and recovery (supported by all 3 transaction managers). > I'll work on more thorough testing in the coming days... > > Guillaume > > 2017-06-20 16:49 GMT+02:00 Timothy Ward <[email protected]>: > > > > > On 20 Jun 2017, at 15:28, Guillaume Nodet <[email protected]<mailto:gnod > > [email protected]>> wrote: > > > > 2017-06-20 12:53 GMT+02:00 Timothy Ward <[email protected]<mailto: > > [email protected]>>: > > > > Hi Guillaume, > > > > The OSGi Alliance is an open organisation, and a number of OPS4j > > developers are already members via their companies. There is absolutely > > nothing preventing them from getting involved with the Alliance, nor > > preventing any non-members from joining. > > > > On the other hand to maintain the openness of its standards the OSGi > > Alliance must have a strict IP policy, one that prevents it from > consuming > > arbitrary code or IP from external sources. If OPS4j are able to get to a > > compatible place contribution-wise then I'm sure you'd see a flow of work > > in the other direction too. > > > > As for Aries Tx Control - a Narayana based XA implementation would be a > > great addition, as would JMS support. > > > > > > I agree, I may look at it in the future, but that would be easily based > on > > what I'm proposing here. Aries tx-control does not necessarily have to > > host the pooling code, but rather the rfc 220 integration code imho. > > > > > > > > Wrapping the Geronimo transaction manager is deliberate for three > reasons: > > > > * the javax.transaction package is toxic due to its split package in the > > JRE. Hiding all of the JTA code allows the impl to work without system > > packages being declared when launching the OSGi framework. > > > > > > That’s not specific to the Geronimo TM afaik. > > > > This is not specific to the Geronimo TM, but it is a reason that wrapping > > a TM is preferable to consuming one from another bundle. Wrapping lets > the > > JTA package usage be purely internal, and avoids the toxic class space > > issues. > > > > > > > > > > * by being Geronimo specific the implementation can offer last > participant > > support > > > > > > I don't think that's true either. Geronimo TM itself offers no support > for > > enlisting local resources. What tx-control does is wrap local resources > > with the LocalXAResourceImpl and just expect everything will be ok. > The > > TM should at list make sure that such wrapped local resources should be > > called last in the prepare phase. Afaik, that's not the case with the > > Geronimo TM. I think the current code should work as is with other TM, > or > > better of some can offer real support for this use case. > > I think Narayana simply requires the XAResource to implement a specific > > interface Last in order to be called last in the prepare phase and lessen > > the possibilities of something bad happening. > > > > > > The Aries TX control implementation wraps the resource and adds it to the > > last place in the resource list. It does this safe in the knowledge that > > Geronimo calls resources in a FIFO order when preparing. This is not > > required to be true for other implementations (which may optimise their > > calls in different ways), and so requires knowledge of the specific > > implementation logic. Similarly, implementing a Narayana interface > requires > > you to know that the implementation will pay attention to the interface, > > and cannot be done speculatively. > > > > > > > > * by being Geronimo specific the implementation can support XA recovery > > > > > > Yes, it's really unfortunate that the JTA spec has not covered this part. > > I'm wondering if we there's a place for a small project which would offer > > an api and wrappers around existing TM so that they could be switched if > > needed, and more importantly, so that code can access those non standard > > features without dealing with the specifics. > > I may try working on this part next, then maybe integrate both into > > tx-control. > > > > I think that this would need to be custom per-provider, but a Narayana > > implementation would definitely be useful. > > > > > > > > This model gives a great level of functionality in an easy to access way > > for users, and I would be keen to keep this option. A pluggable model is > > possible, but would need to be done carefully to ensure that scopes could > > cope with external parties "messing with" the transaction. It would also > > lose the benefits described above, although neither of these things mean > > that it would not be worth adding as an alternative implementation. > > > > Finally - I am not sure why tx Control would have a dependency on pax > jdbc > > (other than as a source of DataSourceFactory services)? This sounds like > it > > would make the Aries project harder to configure and deploy, and I can't > > immediately see what additional benefits it would provide. Can you > clarify? > > > > > > From a high level, pax-jdbc aims at providing DataSourceFactory while > > tx-control aims at integrating those into the transaction api. So it > could > > make sense to layer them. I haven’t looked at the specifics though... > > > > I think that this layering already exists. Right now the Tx Control JDBC > > and JPA providers expect to find and make use of a standard > > DataSourceFactory service. > > > > Regards, > > > > Tim > > > > > > Guillaume > > > > > > > > Regards, > > > > Tim > > > > Sent from my iPhone > > > > On 20 Jun 2017, at 11:00, Guillaume Nodet <[email protected]<mailto:gnod > > [email protected]>> wrote: > > > > 2017-06-16 11:16 GMT+02:00 Richard Nicholson <[email protected]< > > mailto:[email protected]>>: > > > > > > Doesn’t this directly clash with OSGi Alliance Transaction Control > > Specification work going on in Aries? > > > > If so, wouldn’t it make more sense for this community to input into that > > work rather than cause needless confusion / fragmentation? > > > > > > Just a thought. > > > > > > Yeah, I'm a bit skeptic about the relationship between the OPS4j > > community > > and the OSGi Alliance work. It seems to always go in the same > > direction... > > i.e. the guys working at OPS4j should help working on the project defined > > by the guys working at the OSGi Alliance. > > > > That being said, the work in Aries is about defining a new programming > > model for transactions. That's something I'm not really interested in at > > this point. In addition, my initial goal is to have support for JMS + > > Narayana and both aspects are not covered. In particular, it does create > > and wrap the geronimo TransactionManager instead of re-using an external > > one (even the one defined in Aries Transaction for example). > > > > In theory, things should be layered. For example, pax-jdbc provides a > > way > > to expose DataSourceFactory objects in the OSGi registry. Imho, > > pooling > > should be done at this level, as specified in the DataSourceFactory > > interface. So pooling inside aries-tx-control is irrelevant. > > > > This project is even at a lower level and I plan to integrate it below > > pax-jdbc for the jdbc part. > > > > That said, I may have a look at aries-tx-control and see if I can replace > > some of the code there to leverage pax-jdbc and pax-transx more to help > > avoiding confusion and fragmentation. > > > > > > > > On 15 Jun 2017, at 13:55, Toni Menzel <[email protected]<mailto: > > [email protected]>> wrote: > > > > Sounds interesting! > > Two comments: > > > > - i find the whole space of "pooling resources" a not confusing and > > hard > > to find out what you actually really need. So, say once you know you > > want > > takaricp, which other bridges and matching configs do you need so that > > the > > DataSource proxy (for JDBC) appears in your Service Registry. Maybe > > it's > > just me not following bridge provider-projects like Aries too closely. > > Anything that makes setup simpler and offers a wider range of options > > is > > highly welcome. (particularly in the OPS4J community, or how Bndtools > > people say "P A X" ;) > > - Any reason why this is not Pax Tx (org.ops4j.pax.tx) ?Find the > > Transx a bit alien. just an idea. > > > > Thanks for your heads up, JB about karaf-boot. Was wondering what > > happened > > to it. > > > > Toni > > > > > > On Thu, Jun 15, 2017 at 1:58 PM, Achim Nierbeck < > > [email protected]<mailto:[email protected]> > > > > wrote: > > > > Hi Guillaume, > > > > sounds like a good idea to me, and the pax space like the perfect eco > > system :) > > > > regards, Achim > > > > 2017-06-15 10:20 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: > > > > +1 > > > > It sounds like a good idea and definitely a good candidate for PAX. > > > > By the way, on my side, I did good progress on: > > - karaf sample & new dev guide > > - some new updates on karaf-boot > > - ServiceMix APIMan for API/Service Discovery, Management, Gateway > > But I will send an update in separate threads. > > > > Regards > > JB > > > > > > On 06/15/2017 09:57 AM, Guillaume Nodet wrote: > > > > I began to work on a small project which aims at providing support > > for > > pooled XA-enabled connections for JDBC and JMS. > > > > For JDBC, the problem was already solved in pax-jdbc by using either > > pax-jdbc-pool-aries when deploying the Aries/Geronimo transaction > > manager, > > and by using pax-jdbc-pool-narayana when using the Narayana > > transaction > > manager. > > > > However, there's absolutely no support for JMS. > > > > So what I've been doing is to reuse the geronimo JCA connector, make > > it > > independent on Geronimo TM and add support for Narayana, use a clone > > of > > the > > old tranql adapter for JDBC and rewrite a new JMS 2.0 compatible > > adapter > > for JMS. > > > > It's not in a usable state yet, but I wanted to give an heads-up. > > My plan is to make the pooling almost transparent in OSGi, and reuse > > it > > instead of the connection pooling I added to Karaf a few weeks ago > > which > > does not support XA or recovery: > > https://github.com/apache/karaf/tree/master/jms/pool > > and maybe to plug it into pax-jdbc to replace pax-jdbc-pool-aries > > and > > pax-jdbc-pool-narayana. > > > > The source code is currently available at: > > https://github.com/gnodet/org.ops4j.pax.transx > > > > > > Cheers, > > > > > > -- > > Jean-Baptiste Onofré > > [email protected] > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > > > > > > -- > > > > Apache Member > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > > Committer & > > Project Lead > > blog <http://notizblog.nierbeck.de/> > > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > > > Software Architect / Project Manager / Scrum Master > > > > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > > > > > > -- > ------------------------ > Guillaume Nodet >
