4 Replies Latest reply on Sep 23, 2011 11:57 AM by mauromol

    Moving the transactional JDBC driver to IronJacamar




      We are considering removing our code that provides the transactional JDBC driver functionality in favour of providing integration with IronJacamar for connection management to the XA resources.


      We are soliciting feedback from our community as to your preference in regards this change.


      Thanks for reading,


        • 1. Re: Moving the transactional JDBC driver to IronJacamar

          We will now proceed with this work. The Jira to track is: https://issues.jboss.org/browse/JBTM-809

          • 2. Re: Moving the transactional JDBC driver to IronJacamar

            Unfortunately I discovered this thread just now, although I talked about this topic with Mark Little last October in: http://community.jboss.org/message/565137.


            Is there any documentation that explains what is going on this subject? Will JBossTS be still usable for JDBC connections? In what would consist the migration?


            We're using JBossTS in a JTA infrastructure where database queries are done through JDBC. The client code just uses JDBC connections (obtained through the transactional driver), while the global JTA transaction is controlled using Spring JTA transaction manager. The JBossTS backend, through the transactional driver and some of our glue code, is obtaining JTA connections through XA data sources created using the DynamicClass mechanism. We're working outside JEE, just plain Tomcat + JBossTS + Spring.


            How will the scenario change with JCA?



            • 3. Re: Moving the transactional JDBC driver to IronJacamar

              Hi Mauro,


              I will get back to you with a more detailed response shortly, but the first thing to reassure you is that the project will be functionally equivalent after the change so you will still be able to use JDBC connections.


              The idea is to use/embed IronJacamar as a JCA contained which allows us to configure the JDBC XA datasources inside IronJacamar and so no longer maintain the transactional driver itself in the TS codebase, separation of concerns and all that.


              If there was anything that would be functionally affected (i.e. that cannot be configured around) we will not adopt this approach. The main question around this at the moment is how to hand standalone JTS, and this may require some work on IronJacamar to support configuring JBTM in JTS mode.


              Hope this helps to clarify,


              • 4. Re: Moving the transactional JDBC driver to IronJacamar

                Hi Tom,

                first of all thank you for this first answer.


                I had a very quick look at the IronJacamar documentation. Although I see a chapter called "embedded use", I find it quite synthetic, so my first concern is how easy would be to use the JCA connector in an embedded way, I mean outside a JEE container, without needing JNDI or such.

                We spent a lot of effort to make JBossTS work embedded in our application, submitted bugs and helped to fix them (or, at least, to understand them). Right now, our infrastructure is like this:


                • the client code requests a plain JDBC connection to a proprietary ConnectionManager; it uses the connection to do SQL statements; after that, the global JTA transaction is committed or rolled back through the use of Spring JtaTransactionManager
                • our ConnectionManager simply has a reference to a DataSource implementation which pulls connections from a JDBC driver (without pooling); in our case, the JDBC driver is the JBossTS transactional driver; on the other hand our Spring JtaTransactionManager is configured in order to use the JBossTS JTA transaction manager as the JTA-XA implementation
                • the transactional driver is configured through the use of the dynamic class mechanism; our dynamic class implementation is able to pull XA DataSources based on a proprietary XML-based configuration which tells the dynamic class which JDBC XA implementation driver to use to create XA Data Sources and how to wrap those XA Data Sources in order to provide pooling functionality to XA connections and other adjustments needed to make the whole thing work correctly (things like specific exception handling, "is-same-RM" overriding behaviour and other things alike)


                I don't know anything about JCA connectors, apart from the definition, but quickly reading some documentation, this is the idea of what our system would become. I hope in this way to help you to understand my gaps. Please, correct me if I say something wrong.


                • our client code would not be touched; it would still use plain JDBC connections pulled out from out ConnectionManager in order to make SQL statements; the global JTA transaction will always be controlled through the Spring JtaTransactionManager
                • our ConnectionManager would pull connections from a DataSource provided in some way by the IronJacamar JCA connector embedded in our application; on the other hand, our Spring JtaTransactionManager configuration would not be affected, it would still use the JBossTS JTA transaction manager to orchestrate the global JTA transaction
                • the IronJacamar JCA connector embedded in our application will take care of all the hassle of creating and managing XA Data Sources from the JDBC implementation driver, of doing the connection pooling and of applying implementation-specific hacks and tricks (like the "is-same-RM" overriding thing); to be able to do this, I think it would need some adapter (a resource adapter?) for JDBC-XA; from what I've understand, JCA is also JTA-ready, so I can imagine that this JDBC JCA adapter is also responsible of mapping the JTA transaction orchestration to the JDBC XA connection level... so I may expect that this resource adapter is provided by JBossTS JTA


                Am I right? Am I totally wrong? Are there other things that must be considered in this scenario?


                Thank you very much in advance!