12.2. Datasource Parameters

Common Datasource Parameters

A standard JBoss MBean deployment.
The ObjectName of an MBean service this ConnectionFactory orDataSource deployment depends upon.
The JNDI name under which the Datasource should be bound.
Boolean value indicating whether the jndi-name should be prefixed with java:. This prefix causes the Datasource to only be accessible from within the JBoss Enterprise Platform virtual machine. Defaults to TRUE.
The user name used to create the connection to the datasource.


Not used when security is configured.
The password used to create the connection to the datasource.


Not used when security is configured.
The default transaction isolation of the connection. If not specified, the database-provided default is used.

Possible values for <transaction-isolation>

An SQL statement that is executed against each new connection. This can be used to set up the connection schema, for instance.
An SQL statement that is executed before the connection is checked out from the pool to make sure it is still valid. If the SQL statement fails, the connection is closed and a new one is created.
A class that checks whether a connection is valid using a vendor-specific mechanism.
A class that parses vendor-specific messages to determine whether SQL errors are fatal, and destroys the connection if so. If empty, no errors are treated as fatal.
Whether to monitor for unclosed Statements and ResultSets and issue warnings when they haven't been closed. The default value is NOWARN.
The number of prepared statements per connection to be kept open and reused in subsequent requests. They are stored in a Least Recently Used (LRU) cache. The default value is 0, meaning that no cache is kept.
When the <prepared-statement-cache-size> is non-zero, determines whether two requests in the same transaction should return the same statement. Defaults to FALSE.

Example 12.1. Using <share-prepared-statements>

The goal is to work around questionable driver behavior, where the driver applies auto-commit semantics to local transactions.
       Connection c = dataSource.getConnection(); // auto-commit == false
       PreparedStatement ps1 = c.prepareStatement(...);
       ResultSet rs1 = ps1.executeQuery();
       PreparedStatement ps2 = c.prepareStatement(...);
       ResultSet rs2 = ps2.executeQuery();
This assumes that the prepared statements are the same. For some drivers, ps2.executeQuery() automatically closes rs1, so you actually need two real prepared statements behind the scenes. This only applies to the auto-commit semantic, where re-running the query starts a new transaction automatically. For drivers that follow the specification, you can set it to TRUE to share the same real prepared statement.

Whether to enable query timeout based on the length of time remaining until the transaction times out. Defaults to FALSE.
The maximum time, in seconds, before a query times out. You can override this value by setting <set-tx-query-timeout> to TRUE.
A pointer to the type mapping in conf/standardjbosscmp.xml. A legacy from JBoss4.
Whether to validate the connection when the JCA layer matches a managed connection, such as when the connection is checked out of the pool. With the addition of <background-validation> this is not required. It is usually not necessary to specify TRUE for <validate-on-match> in conjunction with specifying TRUE for <background-validation>. Defaults to TRUE.
Whether to attempt to prefill the connection pool to the minimum number of connections. Only supporting pools (OnePool) support this feature. A warning is logged if the pool does not support prefilling. Defaults to TRUE.
Background connection validation reduces the overall load on the RDBMS system when validating a connection. When using this feature, EAP checks whether the current connection in the pool a seperate thread (ConnectionValidator). <background-validation-minutes> depends on this value also being set to TRUE. Defaults to FALSE.
Background connection validation reduces the overall load on the RDBMS system when validating a connection. Setting this parameter means that JBoss will attempt to validate the current connections in the pool as a separate thread (ConnectionValidator). This parameter's value defines the interval, in milliseconds, for which the ConnectionValidator will run. (This value should not be the same as your <idle-timeout-minutes value.)
The maximum time, in minutes, before an idle connection is closed. A value of 0 disables timeout. Defaults to 15 minutes.
Whether the connection should be locked to the transaction, instead of returning it to the pool at the end of the transaction. In previous releases, this was true for local connection factories and false for XA connection factories. The default is now true for both local and XA connection factories, and the element has been deprecated.
Enables interleaving for XA connection factories.
How often, in minutes, the ConnectionValidator runs. Defaults to 10 minutes.


You should set this to a smallervalue than <idle-timeout-minutes>, unless you have specified <min-pool-size> a minimum pool size set.
<url-delimiter>, <url-property>, <url-selector-strategy-class-name>
Parameters dealing with database failover. As of JBoss Enterprise Platform 5.1, these are configured as part of the main datasource configuration. In previous versions, <url-delimiter> appeared as <url-delimeter>.
An implementation of org.jboss.resource.adapter.jdbc.StateConnectionChecker that decides whether SQLExceptions that notify of bad connections throw the org.jboss.resource.adapter.jdbc.StateConnectionException exception.
The maximum number of connections allowed in the pool. Defaults to 20.
The minimum number of connections maintained in the pool. Unless <prefill> is TRUE, the pool remains empty until the first use, at which point the pool is filled to the <min-pool-size>. When the pool size drops below the <min-pool-size> due to idle timeouts, the pool is refilled to the <min-pool-size>. Defaults to 0.
The length of time, in milliseconds, to wait for a connection to become available when all the connections are checked out. Defaults to 30000, which is 30 seconds.
Whether to continue trying to acquire a connection from the pool even if the previous attempt has failed, or begin failover. This is to address performance issues where validation SQL takes significant time and resources to execute. Defaults to FALSE.

Parameters for javax.sql.XADataSource Usage

The JDBC driver connection URL string
The JDBC driver class implementing the java.sql.Driver
Used to configure the connections retrieved from the java.sql.Driver.

Example 12.2. Example <connection-property>

       <connection-property name="char.encoding">UTF-8</connection-property>

Parameters for javax.sql.XADataSource Usage

The class implementing the XADataSource
Properties used to configure the XADataSource.

Example 12.3. Example <xa-datasource-property> Declarations

<xa-datasource-property name="IfxWAITTIME">10</xa-datasource-property>
<xa-datasource-property name="IfxIFXHOST">myhost.mydomain.com</xa-datasource-property>
<xa-datasource-property name="PortNumber">1557</xa-datasource-property>
<xa-datasource-property name="DatabaseName">mydb</xa-datasource-property>
<xa-datasource-property name="ServerName">myserver</xa-datasource-property>

The number of seconds passed to XAResource.setTransactionTimeout() when not zero.
When set to FALSE, fixes some problems with Oracle databases.
Pool transactional and non-transactinal connections separately


Using this option will cause your total pool size to be twice max-pool-size, because two actual pools will be created.
Used to fix problems with Oracle.

Security Parameters

Uses the username and password passed on the getConnection or createConnection request by the application.
Uses the identified login module configured in conf/login-module.xml.
Uses the identified login module configured in conf/login-module.xml and other connection request information supplied by the application, for example JMS Queues and Topics.

Parameters for XA Recovery in the JCA Layer

The user with credentials to perform a recovery operation.
Password of the user with credentials to perform a recovery operation.
Security domain for recovery.
Excludes a datasource from recovery.
The fields in Parameters for XA Recovery in the JCA Layershould have a fall back value of their non-recover counterparts: <user-name>,< password> and <security-domain>.