3 Replies Latest reply on Sep 7, 2012 8:41 AM by Wolf-Dieter Fink

    JBoss 7 Without XA Data Sources

    Randy Layman Newbie

      I am porting our application from JBoss 4 to JBoss 7 and have run into a snag.  For a few very specific use cases we use two data sources within the same JTA transaction context (manged via Spring's TransactionProxyFactoryBean).  We want transactions on one data source to not impact the other.  In JBoss 4 we accomplished this by not using XA Data Sources.  This seems to have caused JTA to commit one transaction after the other independently.  For all other use cases, we use a single Data Source and therefore don't need XA functionality.

       

      In moving to JBoss 7, I initially configured the same way -- non-XA data sources.  However when the second data source was first referenced I got a an error message that meant you can't have two non-XA data sources in the same transaction.  Configuring with XA data sources does allow the application to function, but now the two transactions are married together.

       

      Is there anyway to configure JBoss 7 to not use XA transactions in JTA managed transactions?

       

      For the curious, here is our main use case:  In the course of fulfilling an order from customers we charge their credit card and we configure their newly purchased service.  We never, ever, want the bank to have a record of a credit card transaction that we don't.  So we have a seperate database (and thus data source) for the credit card transactions.  And we want those transactions to always commit, regardless of any issues we might have configuring their service that causes a rollback.

       

      If it is relevant we are using JBoss 7.1.1-Final connecting to Postgres 8 (with the Postgres 9 database driver) running on JDK 1.6.

        • 1. Re: JBoss 7 Without XA Data Sources
          Wolf-Dieter Fink Master

          Mmmmh,

          I'm not sure at the moment what the spec recommend....

          But I suppose it is a fuzzy transaction handling and each container might handle it different.

           

          I would design it in a way that the credidcard part is a separate transaction (new Bean @Transaction.RequiresNew).

          In this case it is clean that and when the Tx is commited. In your case the CreditCard Tx is commited at the end of your use case, so if you have an Exception after the CC is charged this Tx is also rolled back.

          The only difference is the small timeslice where your code is finised and both Tx should commited.

           

          So I would think that the behavior of AS7 is better and avoid Tx trouble and fuzzy behavior, but it might be a matter of opinion

          • 2. Re: JBoss 7 Without XA Data Sources
            Randy Layman Newbie

            I'll look deeper at applying that suggestion to our code.  I'm not sure how straight forward that would be (there is some intermingling of transactions as we first authorize, then perform the actions that don't cost us money, then charge, then perform the actions that cost us money). 

             

            Is there not a way to bring back the JBoss 4 behavior of having the transaction manager handle each transaction possible?

            • 3. Re: JBoss 7 Without XA Data Sources
              Wolf-Dieter Fink Master

              No because if you use container managed transaction the contract with the Spec is

              - success or BusinessException without rollback annotation -> all resorces are committed

              - fail, RuntimeException or B.Exception with rollback annotation -> all resources are rolled back

               

              So the behavior is correct.

              You might use BeanManagedTx or you mark your CMT Beans accordingly.

              E.g. Main SLSB without transaction call different SLSB's to charge and perform action 'that cost money'

              This will work in all JEE conform servers in the same way.

               

              Also I suppose that the AS5 and AS6 might also different in that case.