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 Wed, 21 Jun 2017 12:24:52 GMT
Thx for the openness.

I think I do understand what you mean.  You stated your goals clearly, but
mine are different.  What I need right now is JMS Pooling + Narayana
integration.  I have no interest now in DS integration and no interest in
supporting the Geronimo TM.  Just for the record, I don't have any real
problem with the Geronimo TM but for the fact that I'm the only one having
done commits on it for the past 5 years.

That said, I think it would be fairly easy to implement on top of the being
discussed project.  The two projects can be easily layered as shown by the
quick integration I just wrote:


https://github.com/gnodet/aries/blob/tx-control-jms/tx-control/tx-control-provider-jms-xa/src/test/java/org/apache/aries/tx/control/jms/xa/JMSTest.java

I'll look into abstracting the transaction manager layer + LRC + recovery.
I think that's definitely a missing piece of software in this area.

Guillaume

2017-06-20 23:22 GMT+02:00 mit_jones <tim.jones@mccarthy.co.nz>:

> Hi Guillaume,
>
> So as to openly declare by bias I will state my interest in this
> conversation. My company commissioned Paremus to provide a DS solution for
> transaction control of JPA and JDBC resources which ultimately led to Aries
> tx-control.
>
> Your proposal sounds great, it really does, however I will explain how we
> came to the decision to comission Paremus which I am hoping may then sway
> your decsion as to where it should be implemented.
>
> The product we develop was based upon SpringDM which given the future (or
> lack of it) forced us to look for an alternative, we decided to migrate to
> a
> DS based solution but soon realised there was a lack of transactional
> solutions for DS. At the time I was aware of the Everit transaction-helper
> and a partially completed transactional solution for DS, that being the
> aries-jpa JpaTemplate solution. I had some early conversations with
> Christian about adding new functionality to the JpaTemplate solution such
> as
> support for JDBC, not rolling back for specific exceptions, raised a few
> bugs on JIRA but  wasn't confident that I could recomend it as a solution
> given the lack of tests and most importantly no specification to back the
> implementation.
>
> The solution we now have is tx-control backed by RFC-221 with a
> implementation that covers the extra functionality we asked for such as
> last
> gambit wins and has 2500+ lines of test code.
>
> Currently if one was to embark upon adopting OSGi we are faced with a
> multitude of choices Blueprint/DS/CDI/iPOJO ... and solutions provided by
> Aries/Pax/Enroute/Everit/Amdatu ... For you and perhaps many readers the
> choices are obvious but in my opinion it is not obvious and even more
> difficult to access the quality of the solutions. One thing that is
> indisputable is whether a solution is backed by a specification and
> therefore necessarily has controls to enforce a certain level of compliance
> => quality, this in my opinion is very important, although no guarantee it
> is probably the best assurance an adopter can have that the
> component/framework they are using will survive longer term.
>
> I have followed the Aries/Karaf/Pax forums closely enough over the past few
> years to see that there is tension between groups who belong and don't
> belong to the OSGi Alliance. I think this is really unfortunate because it
> has led and is continuing to led to fragmentation in the OSGi community as
> a
> whole which manifests itself in multiple solutions/options making it really
> difficult for an adopter of the technology to know which to choose.
>
>
> To add JMS support into the tx-control project would add to an already well
> designed solution, that already has good documentation, test support and
> not
> lead to yet more fragmentation. I presume the specification could be added
> to as needed if required.
>
> Unfortunately my company does not have an immediate need for transactional
> JMS otherwise I would be able offer more bribery in the form of $$ :)
>
> Tim J.
>
>
>
>
>
> --
> View this message in context: http://aries.15396.n3.nabble.c
> om/Re-PROPOSAL-New-pax-project-transx-tp4035366p4035371.html
> Sent from the Aries - Dev mailing list archive at Nabble.com.
>



-- 
------------------------
Guillaume Nodet

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