4 Replies Latest reply on Dec 28, 2007 4:48 PM by marklittle

    JBossTSRecovery example on JBossAS 4.2.1GA using SQL Server

    ratrask

      This is a continuation of a thread on SQL Server and recovery that was starting to diverge too much from the original topic, so I thought I should start a new thread.

      I have been trying to get the Transaction Recovery code from the Wiki http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossTSRecovery to work with the 4.2 line of JBoss AS. In particular the test code for the XA Recovery mentioned at the bottom of the Wiki page.

      I have a question in regard to an earlier statement you made.


      If I can follow this rabbit trail for a bit longer, I got the first test to run correctly by just copying the jbossjta-properties.xml file from my server conf directory to the directory into the directory I was runnig in. I was not able to run the jts test, because I could not find a jar file that had the ORB classes in it. I suspect it is not a part of 4.2.1
      Missing classes were
      com.arjuna.orbportability.*
      com.arjuna.ats.internal.jts.ORBManager
      com.arjuna.ats.jta.TransactionManager



      No. You need to download JBossTS (JTS) separately and install.


      What is the difference between the JBossTS that comes with the download, and the transaction service in use by JBoss 4.2.X which makes use of the Arjuna code. The integration road map indicates that arjuna is now built in to JBossAS 4.2.X http://labs.jboss.com/jbosstm/resources/integrationroadmap.htmland this seems to be correct. I down loaded the distribution anyway, but ORBManager is not in any of the jar files, so I don't see how installing JBOSS_TS_4_2_3 can help. Did you think I was running with a 4.0.X version of JBossAS? The installation instructions all reference 4.0.X versions of JBoss. Even if it is necessary to install JBOSS_TS_4_2_3 for the JTS example, is it necessary for the JDBC based transaction recovery?

      The README.txt file has some incorrect information about setting up the JDBC recovery module in the jbossjta-properties file. on line 25 it has:
      <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery1"
      value="com.arjuna.ats.internal.jdbc.recovery.JNDIXARecovery;jdbcxarecovery1.xml"/>

      The JNDIXARecovery should be JDBCXARecovery to match the source in the example. Line 34 of the README.txt file shows the correct configuration.

      With that aside out of the way, after I corrected the configuration problem, I got the following error messages:
      15:32:43,006 INFO [Server] JBoss (MX MicroKernel) [4.2.1.GA (build: SVNTag=JBoss_4_2_1_GA date=200707131605)] Started in 1m:45s:161ms
      15:32:53,101 ERROR [STDERR] java.lang.ClassCastException: org.jboss.resource.adapter.jdbc.WrapperDataSource
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery.createDataSource(JDBCXARecovery.java:174)
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery.hasMoreResources(JDBCXARecovery.java:141)
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:679)
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
      15:32:53,101 ERROR [STDERR] java.lang.ClassCastException: org.jboss.resource.adapter.jdbc.WrapperDataSource
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery.createDataSource(JDBCXARecovery.java:174)
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery.hasMoreResources(JDBCXARecovery.java:141)
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:679)
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
      15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
      15:35:03,118 ERROR [STDERR] java.lang.ClassCastException: org.jboss.resource.adapter.jdbc.WrapperDataSource


      Which just repeats every 3 minutes.

      It is not clear to me how to resolve this issue. I do not believe that an XADataSource is availiable through JNDI. Perhaps I could write some kind of specialized JCA adaptor which would provide implement the XADatasource interface, or alternatively create a specialization of WrapperDataSource which would provide access to a XAConnection, but these approaches seem wrong to me.

      I have stepped through the code, and found that it is getting parametrized correctly. I have also confirmed that the datasource being retrieved is my DefaultDS, which is an XA datasource, and that the WrapperDataSource contains an XAManagedConnectionFactory. I tried casting the connection that was returned as an XAConnection, but that throws a class cast exception.

      Another piece of information is that the com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery is in the jbossjta.jar. so the instructions to copy the xarecovery.jar created by the ant build is not necessary. Since I am pretty sure that this code is broken, it should probably be removed.

      I'm kind of stuck until until I get some direction.


        • 1. Re: JBossTSRecovery example on JBossAS 4.2.1GA using SQL Ser
          marklittle

           

          "ratrask" wrote:
          This is a continuation of a thread on SQL Server and recovery that was starting to diverge too much from the original topic, so I thought I should start a new thread.


          Good idea, thanks.


          I have been trying to get the Transaction Recovery code from the Wiki http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossTSRecovery to work with the 4.2 line of JBoss AS. In particular the test code for the XA Recovery mentioned at the bottom of the Wiki page.


          I still haven't had a chance to look at the JNDI recovery code you mentioned. I think it was donated by Arjuna back in 2006 and may be out-of-date now.


          I have a question in regard to an earlier statement you made.

          If I can follow this rabbit trail for a bit longer, I got the first test to run correctly by just copying the jbossjta-properties.xml file from my server conf directory to the directory into the directory I was runnig in. I was not able to run the jts test, because I could not find a jar file that had the ORB classes in it. I suspect it is not a part of 4.2.1
          Missing classes were
          com.arjuna.orbportability.*
          com.arjuna.ats.internal.jts.ORBManager
          com.arjuna.ats.jta.TransactionManager



          No. You need to download JBossTS (JTS) separately and install.


          What is the difference between the JBossTS that comes with the download, and the transaction service in use by JBoss 4.2.X which makes use of the Arjuna code. The integration road map indicates that arjuna is now built in to JBossAS 4.2.X


          The
          local JTA implementation is what we ship in AS by default.


          http://labs.jboss.com/jbosstm/resources/integrationroadmap.htmland this seems to be correct. I down loaded the distribution anyway, but ORBManager is not in any of the jar files, so I don't see how installing JBOSS_TS_4_2_3 can help.


          ORBManager is part of the ORB Portability harness. It ships as part of the JTS implementation.

          Did you think I was running with a 4.0.X version of JBossAS? The installation instructions all reference 4.0.X versions of JBoss. Even if it is necessary to install JBOSS_TS_4_2_3 for the JTS example, is it necessary for the JDBC based transaction recovery?


          No, it's not necessary at all. However, if the example code uses it then you'll need it.


          The README.txt file has some incorrect information about setting up the JDBC recovery module in the jbossjta-properties file. on line 25 it has:
          <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery1"
          value="com.arjuna.ats.internal.jdbc.recovery.JNDIXARecovery;jdbcxarecovery1.xml"/>

          The JNDIXARecovery should be JDBCXARecovery to match the source in the example. Line 34 of the README.txt file shows the correct configuration.

          With that aside out of the way, after I corrected the configuration problem, I got the following error messages:
          15:32:43,006 INFO [Server] JBoss (MX MicroKernel) [4.2.1.GA (build: SVNTag=JBoss_4_2_1_GA date=200707131605)] Started in 1m:45s:161ms
          15:32:53,101 ERROR [STDERR] java.lang.ClassCastException: org.jboss.resource.adapter.jdbc.WrapperDataSource
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery.createDataSource(JDBCXARecovery.java:174)
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery.hasMoreResources(JDBCXARecovery.java:141)
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:679)
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
          15:32:53,101 ERROR [STDERR] java.lang.ClassCastException: org.jboss.resource.adapter.jdbc.WrapperDataSource
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery.createDataSource(JDBCXARecovery.java:174)
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery.hasMoreResources(JDBCXARecovery.java:141)
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:679)
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:179)
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237)
          15:32:53,101 ERROR [STDERR] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163)
          15:35:03,118 ERROR [STDERR] java.lang.ClassCastException: org.jboss.resource.adapter.jdbc.WrapperDataSource


          Which just repeats every 3 minutes.

          It is not clear to me how to resolve this issue. I do not believe that an XADataSource is availiable through JNDI.


          Realising that I haven't looked at the code in a while and haven't tested your exact configuration, what is it you're publishing into JNDI? It definitely needs to be an XADataSource.

          Perhaps I could write some kind of specialized JCA adaptor which would provide implement the XADatasource interface, or alternatively create a specialization of WrapperDataSource which would provide access to a XAConnection, but these approaches seem wrong to me.


          Well for JBossAS

          I have stepped through the code, and found that it is getting parametrized correctly. I have also confirmed that the datasource being retrieved is my DefaultDS, which is an XA datasource,


          Strange, because the line number would indicate it isn't an XADataSource.


          and that the WrapperDataSource contains an XAManagedConnectionFactory. I tried casting the connection that was returned as an XAConnection, but that throws a class cast exception.

          Another piece of information is that the com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery is in the jbossjta.jar. so the instructions to copy the xarecovery.jar created by the ant build is not necessary. Since I am pretty sure that this code is broken, it should probably be removed.


          It is out-of-date. I'll update the wiki page when I get a chance. However, the JDBCXARecovery code is not part of the mainline distribution, so you should be able to try with that.


          I'm kind of stuck until until I get some direction.


          • 2. Re: JBossTSRecovery example on JBossAS 4.2.1GA using SQL Ser
            ratrask

            To clarify these statements.

            ... what is it you're publishing into JNDI? It definitely needs to be an XADataSource.

            I have stepped through the code, and found that it is getting parametrized correctly. I have also confirmed that the datasource being retrieved is my DefaultDS, which is an XA datasource,

            Strange, because the line number would indicate it isn't an XADataSource.
            When I say it is a XA DataSource what I mean is that it is defined in my mssql-xa-ds.xml file to be an <xa-datasource>. This is the only way that I am aware of to define an XA DataSource.

            With this configuration, when I retrieve the object from JNDI, what I get is an org.jboss.resource.adapter.jdbc.WrapperDataSource, not a javax.sql.XADataSource as is expected in the com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery source code. i.e.
            Context context = new InitialContext();
             Object obj = context.lookup(_dbName);
             _dataSource = (DataSource) obj;


            While debugging when I set a breakpoint on the the line "_dataSource = (DataSource) obj;" obj is a WrapperDataSource instance. The managed connection factory member variable is a XAManagedConnectionFactory object. Is there some other way that I should be defining the XA DataSource?

            For completeness, here is the content of my mssql-xa-ds.xml file.

            <datasources>
             <xa-datasource>
             <jndi-name>DefaultDS</jndi-name>
             <track-connection-by-tx/>
             <isSameRM-override-value>false</isSameRM-override-value>
             <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
             <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
             <xa-datasource-property name="DatabaseName">jboss</xa-datasource-property>
             <xa-datasource-property name="SelectMethod">cursor</xa-datasource-property>
             <xa-datasource-property name="User">jboss</xa-datasource-property>
             <xa-datasource-property name="Password">jboss</xa-datasource-property>
             <xa-datasource-property name="URL">jdbc:sqlserver://localhost:1961</xa-datasource-property>
             <!-- sql to call when connection is created -->
             <new-connection-sql>select 1</new-connection-sql>
             <!-- sql to call on an existing pooled connection when it is obtained from pool -->
             <check-valid-connection-sql>select 1</check-valid-connection-sql>
            
             <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml -->
             <metadata>
             <type-mapping>MS SQLSERVER2000</type-mapping>
             </metadata>
             </xa-datasource>
            </datasources>


            • 3. Re: JBossTSRecovery example on JBossAS 4.2.1GA using SQL Ser
              ratrask

              whoops sorry did not mean to confuse things further. The code snipit that was in my last email was after I had modified it a bit to see what was going on. The original source was

              Context context = new InitialContext();
               _dataSource = (XADataSource) context.lookup(_dbName);


              • 4. Re: JBossTSRecovery example on JBossAS 4.2.1GA using SQL Ser
                marklittle

                OK, now it starts to make sense. The donated JNDI code is meant for when running outside the application server, when XADataSources are available directly. Because you're running within AS this will need some slight modification.