JBoss.org Community Documentation

13.4.3.1. Pooling parameters

  • <no-tx-separate-pools> - whether separate subpools should be created for connections inside and outside JTA transactions (default false).

  • <min-pool-size> - the minimum number of connections in the pool (default 0 - zero)

  • <max-pool-size> - the maximum number of connections in the pool (default 20)

  • <blocking-timeout-millis> - the length of time to wait for a connection to become available when all the connections are checked out (default 5000 == 5 seconds, from 3.2.4 it is 30000 == 30 seconds)

  • <idle-timeout-minutes> - the number of minutes after which unused connections are closed (default 15 minutes)

  • <track-connection-by-tx> - whether the connection should be "locked" to the transaction, returning it to the pool at the end of the transaction; in pre-JBoss-5.x releases the default value for Local connection factories is true and false for XA; since JBoss-5.x the default value is true for both Local and XA and the element is deprecated.

  • <interleaving/> - enables interleaving for XA connection factories (this feature was added in JBoss-5.x)

  • <prefill> - whether to attempt to prefill the connection pool to the minimum number of connections. NOTE: only supporting pools (OnePool) support this feature. A warning can be found in the logs if the pool does not support this. This feature is available in JBoss 4.0.5 and above.

  • <background-validation> - In JBoss 4.0.5, background connection validation was added to reduce the overall load on the RDBMS system when validating a connection. When using this feature, JBoss will attempt to validate the current connections in the pool as a seperate thread (ConnectionValidator).

  • <background-validation-minutes> - The interval, in minutes, that the ConnectionValidator will run. NOTE: It is prudent to set this value to something greater or less than the <idle-timeout-minutes>

  • <use-fast-fail> - Whether or not to continue to attempt to acquire a connection from the pool even if the nth attempt has failed. False by default. This is to address performance issues where SQL validation may take significant time and resources to execute.