7 Replies Latest reply on Nov 21, 2014 12:32 PM by mmusgrov

    Using TransactionalDriver with JBoss Modules


      This post is taken from a discussion raised in JBTM-2280


      Using TransactionalDriver with JBoss Modules is proving difficult because the way it is implemented creates a circular dependency between narayana and the client module. Would it be possible to offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands me 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. Something like

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


      This would also need to work in a recovery scenario where the application is no longer present so passing classes/objects directly to narayana will not necessarily work.

        • 1. Re: Using TransactionalDriver with JBoss Modules

          Hi Mike,


          I think we need something like a "DirectionNonRecoverableConnection" that can take an instance of an XAResource. We won't be able to use BasicXARecovery to handle the recovery but a simple XAResourceRecovery can be provided.



          • 2. Re: Using TransactionalDriver with JBoss Modules


            • 3. Re: Using TransactionalDriver with JBoss Modules

              Sorry, it was a typo (i meant DirectNonRecoverableConnection - and this was just to be consistent with the naming of the other connection types, however I have subsequently thought it was a bit open to misinterpretation and renamed it to: ProvidedXADataSourceConnection). Unfortunately the forum was down when I tried to clarify. This PR should help explain what I am thinking of: https://github.com/jbosstm/narayana/pull/758/files

              The reason the naming was as such is because is it is "not recoverable" in itself in terms of "RecoverableXAConnection" and its assistant BasicXARecovery. I.e it needs a com.arjuna.ats.jta.recovery.XAResourceRecovery to be provided by user code. The normal transactional driver connection stuff is recoverable on its own because you can encode the url etc and class names so enough info exists to recreate what you need within Narayana. The thing is that is not classloader friendly so the dynamicClass for example has to be available to Narayana classloader which means it won't work in a JBoss Modules environment because it would result in a circular dependency between the TM and the user code.

              • 4. Re: Using TransactionalDriver with JBoss Modules

                If no-one has an objections to the proposed implementation in Allow the user to provide a reference to an XADataSource by tomjenkinson · Pull Request #758 · jbosstm/narayana · GitHub then I will go ahead and create a new for the new feature, update the PR to reference it and get it merged.

                • 5. Re: Using TransactionalDriver with JBoss Modules

                  I assume this won't be back ported since it changes the public API?

                  • 6. Re: Using TransactionalDriver with JBoss Modules

                    Hi guys,


                    Just so you know I have updated the PR. Although I don't anticipate backporting this I think it should be OK for backport as the only parts of the public API that I have altered now are in ArjunaJTA/jdbc/classes/com/arjuna/ats/jdbc/TransactionalDriver.java I have added a to add a new final which a user can use in their configuration properties to enable the new behavior. Existing behavior is intended to remain identical to before. Let me know if you do think I have broken something and I can try to address that to give us opportunity to back port should it be necessary.


                    Mike, can you have a look and let me know if you think this will address your needs? If so I will raise the Jira and we can think about merging it before 5.0.4.




                    • 7. Re: Using TransactionalDriver with JBoss Modules

                      The PR is its initial form worked very well for me, thanks. I haven't pulled the changes you mentioned in the previous comment and done a retest - I will do that after I've cleared the current BZ I am working on.


                      I don't have a requirement for backporting since I can just package the snapshot (or wait for 5.0.4-Final and upload that to the ceylon herd module repository.