1 Reply Latest reply on Sep 28, 2004 10:12 AM by squeak

    Getting JBossMQ to use a local DS as an XA resource?

    squeak

      I must be missing something, because I am sure this has been answered, but I can't seem to find the answer.

      My scenario: I have the typical situation where inside an EJB call, I do some work and update my DB via a local resource (MSSQL), and then place a messasge on a JMS queue. I am using java:/JmsXA as my lookup for the QueueConnectionFactory.

      Given this scenario, and the fact that 4.0 has the Last Resource Gambit, I would assume that this would work great. But, I keep getting the 'Prepare called on a local tx' warning.

      After tracking it down, I realized that it is not my MSSQL DS that is causing the issue (the gamit algorithm skips it fine), but it is in fact DefaultDS that is the issue -- which makes sense. JBossMQ has to save it's information somewhere, and is using HSQL as the default. And that connection is a local resource as well.

      After reading the FAQ's, I realize that I need to change the db that JBossMQ is using to persist it's information. I am happy to change it to use my MSSQL Datasource.

      But, am I not going to run into the same issue? In this scenario, I am always going to have 3 resources: my JDBC work, MQ's JDBC work, and the MQ Spy resource.

      Is there a proper way to configure it so that I can allow my MSSQL DS to be the only local resource, and thus allow the LRG algorithm to work? If I tell MQ to use my MSSQL DS, will it then only count as one resource, and be the allowed local resource in an XA TX?

        • 1. Re: Getting JBossMQ to use a local DS as an XA resource?
          squeak

          To answer my own question -- and to be helpful to everyone else:

          In my situation, once I changed my JMS store to use my datasource that is used for the rest of my application, it then reduced the number of resources that was in my TX from 3 to 2 -- one for all of my DB work, and one for the Spy resource for the queue.

          Given that, it might it very nice because now my MSSQL driver can participate in an XA TX and be non-XA.