Full list of JDBC Provider Configuration Keys

Introduction

In most usecases, only the required configuration keys of DataSources will be used: url, username, password, validationQuery.

The following chapter provides a full list of supported key name patterns.

Ful list of org.clazzes.jdbc.provider datasource configuration keys

The JDBC-Provider supplies applications with Instances of org.apache.commons.dbcp.BasicDataSource from Apache's commons-dbcp project in Version 1.x, version 2.x of JDBC-Provider uses commons-dbcp2's org.apache.commons.dbcp2.BasicDataSource, therefore most values go right into it's setters.

Key
Description
JDBC-Provider Version
accessToUnderlyingConnectionAllowed

Should not matter. Changes have no effect after pool initialization.

1.x and 2.x
connectionInitSqlsList of SQL Statements to be executed when a physical connection is first created. Comma separated. Changes have no effect after pool initialization.1.x and 2.x
connectionPropertiesConnection properties.1.x and 2.x
defaultAutoCommitDefault autocommit state. Should not matter for well-designed applications. Changes have no effect after pool initialization.1.x and 2.x
defaultCatalogDefault catalog name. Changes have no effect after pool initialization.1.x and 2.x
defaultReadOnly

Changes have no effect after pool initialization.

1.x and 2.x
defaultTransactionIsolationChanges have no effect after pool initialization.1.x and 2.x
driverClassName

Optional for common database backends. Name of the database driver to use.

For MySQL, MSSQL, PostgreSQL and Oracle the driver class name is automatically deduced from the JDBC URL.

The class is resolved using the class loader of the jdbc-provider bundle.
This allows for putting JDBC driver on the boot classloader of the OSGi container or creating fragment bundles, which supply JDBC drivers to the jdbc-provider bundle.

1.x and 2.x
initialSizeInitial size of the pool. Changes have no effect after pool initialization.1.x and 2.x
maxActiveMaximum number of active connections that can be allocated at the same time. Use a negative value for no limit.1.x
maxTotalMaximum number of active connections that can be allocated at the same time.2.x, if this value is not set, the value of maxActive will be taken for compatibility reasons.
fastFailValidationWhether conenctions with previous SQL states indicating a server dconnect are immediately evicted.2.x
maxConnLifetimeMillisMaximal connection lifetime in milliseconds2.x
maxIdleMaximum number of connections that can remain idle in the pool.1.x and 2.x
maxOpenPreparedStatementMaximum number of PreparedStatements to pool. Use a negative value for no limit. Changes have no effect after pool initialization.1.x and 2.x
maxWaitThe maximum number of milliseconds that the pool will wait for a connection to be returned before throwing an exception. Use a negative value for no limit.1.x
maxWaitMillisThe same value as maxWait, but for Version 2.x2.x, if this value is not set, the value of maxWait will be taken for compatibility reasons.
minEvictableIdleTimeMillisMinimum amount of time an object may sit idle in the pool.1.x and 2.x
minIdleMinimum number of idle connections in the pool.1.x and 2.x
passwordRequired. JDBC Password. Changes have no effect after pool initialization.1.x and 2.x
poolPreparedStatementsWhether to pool statements or not. Changes have no effect after pool initialization.1.x and 2.x
removeAbandonedWhether abandoned (blocking) queries will be removed form the pool. This is a last-resort option, which has the potential to also evict long-running "ordinary" query.1.x
removeAbandonedOnBorrowWhether abandoned (blocking) queries will be removed form the pool on connection borrow.2.x
removeAbandonedOnMaintenanceWhether abandoned (blocking) queries will be removed form the pool during pool maintenance.2.x
removeAbandonedTimeoutThe timeout in second after which a long-running query is considered as abandoned.1.x and 2.x
testOnBorrowWether the validation query shall be executed before each "borrow" from the pool.1.x and 2.x
testOnReturnWether the validation query shall be executed when a connection is returned to the pool.1.x and 2.x
testOnCreateWhether the validation query will be run immediately after the conenction creation.2.x
testWhileIdleWether the validation query shall be executed regularily to keep the connection alive.1.x and 2.x
timeBetweenEvictionRunsMillisThe time in milliseconds between two runs of the IDLE evictor Runnable.1.x and 2.x
urlRequired. JDBC URL. JDBC URL examples for common databases can be found in our JDBC Snippets. Changes have no effect after pool initialization.1.x and 2.x
usernameRequired. JDBC User. Changes have no effect after pool initialization.1.x and 2.x
validationQueryRequired. Validation query, executed to ensure the application receives a valid connection.
Common validation queries can be found in our JDBC Snippets.
1.x and 2.x

For more supported key patterns take a look at the JavaDoc of the org.clazzes.util.jdbc.provider.JdbcProvider class, i.e. JdbcProvider.html.

Typical JDBC URLs and validation queries can be found in our JDBC Snippets.