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

[earlgrey]

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

[tsmets]

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

Thomas,

[oravecz]

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

[drcharris]

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.