3 Replies Latest reply on May 16, 2002 5:44 AM by Chris Harris

    migration to 2.4.5RC1: debug-info [INFO,XAPoolDataSource] Cr

    Lars Bergmann Newbie

      I get tons of this info (like 100 prints for 1000 entity instantiations) after migration from 2.4.4 to 2.4.5RC1. Is this intended behaviour (what does it mean?) or do I need to debug my code?

      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool
      [INFO,XAPoolDataSource] Creating XA Pool

        • 1. Re: migration to 2.4.5RC1: debug-info [INFO,XAPoolDataSource
          Thomas SMETS Newbie

          I believe you should check your jboss.cml file. Look at the value of the different parameters !

          Thomas,

          • 2. Re: migration to 2.4.5RC1: debug-info [INFO,XAPoolDataSource
            James Cook Newbie

            Same issue for me. My configuration follows this post. The message "Creating XA Pool" is written when the XAPoolDataSource is instantiated. It appears that this class is instantiated in a lazy manner in XADataSourceLoader, when the getSource() method is invoked for the first time. I would surmise that we should only be seeing one "Creating XA Pool" message per XADataSourceLoader, but I am seeing many (even after the app server has started up.)

            Because XADataSourceLoader exercises its pool at system startup, we shouldn't have additional XAPoolDataSource objects created after our server has started. Clearly, not the behavior I am seeing.






            billing_pool
            com.sybase.jdbc2.jdbc.SybXADataSource
            serverName=SOCDB004;networkProtocol=Tds;portNumber=25000;databaseName=testdb
            1200000
            &user;
            20
            &password;
            false
            true
            false
            true
            120000
            1800000
            false
            false
            1.0
            0


            • 3. Re: migration to 2.4.5RC1: debug-info [INFO,XAPoolDataSource
              Chris Harris Newbie

              I was a bit worried about this so I did some investigating. The reason this happens so often is simply that getting the DataSource object from JNDI involves creating a new instance of the DataSource (it's a serializable object, so is copied from the JNDI bind to your calling class, and the default constructor gets called as part of standard deserialisation).

              There's nothing wrong with the behaviour of the DataSource, it's a natural consequence of it being serialised into JNDI.

              This means that every class that looks up the pool from JNDI gets its own copy of the pool - so if you cache the DataSource locally in your beans you will end up with many pools.

              I don't think the behaviour of the pool has changed at all - simply an extra log message is now present which makes it much more explicit when new pools are created.