• Icon: Feature Request Feature Request
    • Resolution: Won't Do
    • Icon: Major Major
    • None
    • None
    • None
    • None

      So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources.

      Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely possible, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI.

      IMO, what the TM should do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all.

      XADataSource xads = youJustDontNeedToCare();
      DataSource ds = narayana.registerDataSource(xads);

      Or something like that. Of course I'm sure I'm missing some subtleties here.

            [JBTM-2280] alternative to JNDI

            Well this sounds great, I hope we can validate that it fixes our specific problem.

            Stephane Epardaud added a comment - Well this sounds great, I hope we can validate that it fixes our specific problem.

            Hi Stephane, I added a feature over here JBTM-2325 it will be in the next version of Narayana - hope it works for you. I created a forum entry over here if you would like to discuss it further: https://developer.jboss.org/message/909177#909177

            Thanks,
            Tom

            Tom Jenkinson added a comment - Hi Stephane, I added a feature over here JBTM-2325 it will be in the next version of Narayana - hope it works for you. I created a forum entry over here if you would like to discuss it further: https://developer.jboss.org/message/909177#909177 Thanks, Tom

            So this was closed and then fixed?

            Stephane Epardaud added a comment - So this was closed and then fixed?

            I have updated the ceylon code to use Toms changes that allow the user to provide the datasource (I will raise a ceylon PR after we do the next narayana release). This change means that the ceylon user no longer needs to register his datasources via JNDI.

            Michael Musgrove added a comment - I have updated the ceylon code to use Toms changes that allow the user to provide the datasource (I will raise a ceylon PR after we do the next narayana release). This change means that the ceylon user no longer needs to register his datasources via JNDI.

            Rejecting as the direct recoverable connection should work. If not, please raise a Jira/discussion against that feature.

            Tom Jenkinson added a comment - Rejecting as the direct recoverable connection should work. If not, please raise a Jira/discussion against that feature.

            Well, I think gavinking_jira tried to refactor it and failed because the TCCL calls were actually working by accident/luck rather than by design. So when he refactored it everything stopped working and he could not figure out how to fix it.

            Stephane Epardaud added a comment - Well, I think gavinking_jira tried to refactor it and failed because the TCCL calls were actually working by accident/luck rather than by design. So when he refactored it everything stopped working and he could not figure out how to fix it.

            I can look into providing an implementation using this approach. Our docs do say "This is not recommended, but provides a fallback for environments where use of JNDI is not feasible" but I do not know why it's not recommended - I will find out.

            But given that we have ceylon.transaction fully working with the JNDI approach why do we need to jettison its use?

            Michael Musgrove added a comment - I can look into providing an implementation using this approach. Our docs do say "This is not recommended, but provides a fallback for environments where use of JNDI is not feasible" but I do not know why it's not recommended - I will find out. But given that we have ceylon.transaction fully working with the JNDI approach why do we need to jettison its use?

            rhn-engineering-mmusgrov: would this be enough to get rid of JNDI for us entirely then?

            Stephane Epardaud added a comment - rhn-engineering-mmusgrov : would this be enough to get rid of JNDI for us entirely then?

            Hi Gavin,

            This would be best as a discussion on the Narayana forum: https://community.jboss.org/en/jbosstm

            Two brief points:

            1. Narayana is not a JCA implementation, its a transaction manager. The core transaction manager is not connection aware, it is however XAResource aware and so for spec compliance the psuedocode you showed would be closest phrased as:
            XADataSource xads = youJustDontNeedTo();
            XAResource xar = xads.getXAConnection().getXAResource();
            narayana.getTransactionManager().getTransaction().enlistResource(xar)

            2. However, we do have something called a transactional driver which does broadly what you are speaking of, its *not in product* but does allow you to pass an XADataSource to it. I have just updated our unit test to use h2 so you can see it in action: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jdbc/tests/classes/com/hp/mwtests/ts/jdbc/basic/JDBC2Test.java

            I think we should close this as not a bug and move the discussion onto the forum.

            Tom

            Tom Jenkinson added a comment - Hi Gavin, This would be best as a discussion on the Narayana forum: https://community.jboss.org/en/jbosstm Two brief points: 1. Narayana is not a JCA implementation, its a transaction manager. The core transaction manager is not connection aware, it is however XAResource aware and so for spec compliance the psuedocode you showed would be closest phrased as: XADataSource xads = youJustDontNeedTo(); XAResource xar = xads.getXAConnection().getXAResource(); narayana.getTransactionManager().getTransaction().enlistResource(xar) 2. However, we do have something called a transactional driver which does broadly what you are speaking of, its * not in product * but does allow you to pass an XADataSource to it. I have just updated our unit test to use h2 so you can see it in action: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jdbc/tests/classes/com/hp/mwtests/ts/jdbc/basic/JDBC2Test.java I think we should close this as not a bug and move the discussion onto the forum. Tom

            Well, I guess it's similar, but not quite the same since that other issue is about the CDI `BeanManager`, not about `DataSource`s.

            Gavin King (Inactive) added a comment - Well, I guess it's similar , but not quite the same since that other issue is about the CDI `BeanManager`, not about `DataSource`s.

            Suggestimate suggests that this is similar to JBTM-2225, which appears to be true, no?

            Stephane Epardaud added a comment - Suggestimate suggests that this is similar to JBTM-2225 , which appears to be true, no?

              thjenkin@redhat.com Tom Jenkinson
              gavinking_jira Gavin King (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: