You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Guillaume Nodet <gn...@apache.org> on 2017/07/06 14:48:27 UTC
Re: [PROPOSAL] New pax project 'transx'
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 <ti...@apache.org>:
>
> On 20 Jun 2017, at 15:28, Guillaume Nodet <gnodet@apache.org<mailto:gnod
> et@apache.org>> wrote:
>
> 2017-06-20 12:53 GMT+02:00 Timothy Ward <timothyjward@apache.org<mailto:
> timothyjward@apache.org>>:
>
> 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 <gnodet@apache.org<mailto:gnod
> et@apache.org>> wrote:
>
> 2017-06-16 11:16 GMT+02:00 Richard Nicholson <puppy_wants_a_hug@me.com<
> mailto:puppy_wants_a_hug@me.com>>:
>
>
> 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 <toni.menzel@rebaze.com<mailto:
> toni.menzel@rebaze.com>> 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 <
> bcanhome@googlemail.com<ma...@googlemail.com>
>
> 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é <jb...@nanthrax.net>:
>
> +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é
> jbonofre@apache.org
> 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
Re: [PROPOSAL] New pax project 'transx'
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <gn...@apache.org>:
> 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 <ti...@apache.org>:
>
> >
> > On 20 Jun 2017, at 15:28, Guillaume Nodet <gnodet@apache.org<mailto:gnod
> > et@apache.org>> wrote:
> >
> > 2017-06-20 12:53 GMT+02:00 Timothy Ward <timothyjward@apache.org<mailto:
> > timothyjward@apache.org>>:
> >
> > 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 <gnodet@apache.org<mailto:gnod
> > et@apache.org>> wrote:
> >
> > 2017-06-16 11:16 GMT+02:00 Richard Nicholson <puppy_wants_a_hug@me.com<
> > mailto:puppy_wants_a_hug@me.com>>:
> >
> >
> > 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 <toni.menzel@rebaze.com<mailto:
> > toni.menzel@rebaze.com>> 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 <
> > bcanhome@googlemail.com<ma...@googlemail.com>
> >
> > 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é <jb...@nanthrax.net>:
> >
> > +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é
> > jbonofre@apache.org
> > 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
>