3 Replies Latest reply on Apr 8, 2016 12:27 PM by haskovec

    Using Narayana JTA under Spring without an XA connection

    haskovec

      At one point in my company we went away from XA connections as we had issues with SQLServer 2008. They fundamentally wouldn't scale and were broken for our traffic volume at the time. We are now on SQLServer 2012, but unwilling to revisit that XA decision as it seems like Microsoft hasn't updated their XA packages or JDBC driver at all in the last 3 years. We ended up switching our Datasources in JBoss EAP to be regular JDBC connections, but we still configured for JTA transactions. While their could be atomicity issues this way, this configuration has largely worked for us for a couple of years now in production (We are running EAP-6.4).

       

      I am experimenting with being able to run our app in other containers (like Tomcat) but I wanted to stay with JBoss Transactions. When I look at the documentation this seems like it isn't possible. I started working on a test case in the spring-boot directory of my forked version of the quickstart repository here: GitHub - haskovec/quickstart: The quickstarts for the narayana project. I think I realize why this is failing which is that I am not starting the RecoveryManager service and registering my Datasource with it. It looks like the Recovery Service only accepts an XA datasource.

       

      Currently for our app, though we run on JBoss in production, when our unit tests execute they use Atomikos to provide the JTA so that we can standup a minimal app under the SpringJunitTestRunner. Atomikos allows you to use a NonXA datasource as well with limitations: https://www.atomikos.com/Documentation/NonXaDataSource

       

      I was able to make the same test that failed in the above github repository pass in my atomikos repository test: GitHub - haskovec/atomikos-transaction-test: Test using Atomikos with Spring with a Non-XA connection in JTA mode with r…

       

      My question is: Is there a way to run JBossTM in standalone mode for JTA with a non XA JDBC Driver and have it sort of work, with limitations or is that not at all possible. If the answer is the latter, I will just convert our app to use Atomikos for both unit tests and production so that we have the option to run either on JBoss or any other container, (or in the future when I convert it to Spring Boot, to an embedded tomcat server if we want). My hope is to stay with the JBossTM as it has worked great for us for a couple of years and switching out transaction managers on an application that services up millions of pages a day is a little nerve racking so I was hoping someone here would have a solution for me.

       

      Thanks,

       

      Jeffrey Haskovec

        • 1. Re: Using Narayana JTA under Spring without an XA connection
          zhfeng

          I tried to add the H2 database config by using the org.apache.commons.dbcp2.managed.BasicManagedDataSource

          @Configuration
          public class H2DataBaseConfig {
              @Autowired
              private TransactionManager tm;
          
              @Bean
              DataSource getDataSource() {
                  BasicManagedDataSource ds = new BasicManagedDataSource();
                  ds.setDriverClassName("org.h2.Driver");
                  ds.setUrl("jdbc:h2:~/test;DB_CLOSE_ON_EXIT=FALSE");
                  ds.setUsername("sa");
                  ds.setPassword("saPassword");
                  ds.setTransactionManager(tm);
          
                  return ds;
              }
          }
          
          
          

           

          The all of the codes could be found on quickstart/spring-boot at nonJTA · zhfeng/quickstart · GitHub

          The testCommit and testRollback work now.

           

          Thanks,

          Amos

          • 2. Re: Using Narayana JTA under Spring without an XA connection
            tomjenkinson

            Hi Jeffrey,

             

            If you are using more than one datasource/JMS/etc and need an atomic outcome you will need to move to using XA for at least one of those resource managers. The database (in your case MsSQL) could be configured as a connectable resource which means we can stash some extra data in a secondary table but the other resource would need to be XA to deliver the right semantics. I am not sure if connectable works out of the box in Spring but it would be great to qualify your use case first.

             

            What is the maximum number of resources you have in each transaction?

            If there are more than one resource do you use XA for all-but-one of them?

             

            The main issue with none-XA datasources is this:

             

            1. begin()

            2. enlist NoneXA1

            3. enlist NoneXA2

            4. Start commit

            5. commit NoneXA1

            6. Crash

             

            With a true none-XA set up. NoneXA2 would never commit and you would have in effect a none-discoverable heuristic.

             

            Hope it helps,

            Tom

            • 3. Re: Using Narayana JTA under Spring without an XA connection
              haskovec

              Hey Tom we do have multiple datasources that are multiple sql server databases. We are definitely aware of the risk with us not using XA, but when we were initially using SQLServer's XA support a couple of years ago, it seemed to be fundamentally broken and didn't scale for our app. At that time our architect ripped out XA and we have run without it since then, but we are aware in a crash situation we could have an issue that we have to clean up. Unfortunately our dataset is too large to switch to another database or an open source database that would work better with XA. I think we have about 2 TB of data and about 40 million users of the system with several million page views daily.

               

              I appreciate your help though as this has been great. I think Amos's help above it tells me enough about how to use JBossTM in my sample app, so I should be able to continue to use it in our main app (as that feels less risky to us than switching to Atomikos as we have 3-4 years of production experience with JBossTM via the JBoss container).