Fwiw, I've rewritten the code coming originally from geronimo connector. I've been reusing some Hikari pool classes and we end up with something faster and more maintainable. I'm going to release a 0.1.0 so that I can commit the integration I've written for pax-jdbc and pax-jms.
Cheers, Guillaume 2017-07-08 9:49 GMT+02:00 Guillaume Nodet <[email protected]>: > I've moved the code to it's final destination: > https://github.com/ops4j/org.ops4j.pax.transx > > I'll work on the README next to provide actually useful information... > > 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 >> >> > > > -- > ------------------------ > Guillaume Nodet > > -- ------------------------ Guillaume Nodet -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
