aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [PROPOSAL] New pax project 'transx'
Date Tue, 20 Jun 2017 14:28:05 GMT
2017-06-20 12:53 GMT+02:00 Timothy Ward <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.


>
> * 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.


>
> * 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.


>
> 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...

Guillaume


>
> Regards,
>
> Tim
>
> Sent from my iPhone
>
> > On 20 Jun 2017, at 11:00, Guillaume Nodet <gnodet@apache.org> wrote:
> >
> > 2017-06-16 11:16 GMT+02:00 Richard Nicholson <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> 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
> >>>
> >>> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message