JDBC Connection Pool
maximumPoolSize) The maximum pool size is the maximum number of both idle and in-use connections that will be maintained by the pool, thus determining the maximum number of connections to the database backend (per web application). A reasonable value for this is best determined by your database environment. A rule of thumb is to set this roughly to (number of db processor cores * 2) + number of harddisks of db.
When the pool reaches this size, and no idle connections are available, getting a connection will block for up to Connection Timeout [milliseconds] milliseconds before timing out.
minimumIdleConnections) Note that IAM creates at least one connection pool per deployed module (e.g. Loginapp, Adminapp, Service-Container). Multiple connection pools are created within a module, if differently configured connection pools are present in the configuration. Keep in mind that in multi-instance setups (active-active or horizontally scaling cloud setups) with n instances, the number of connection pools is multiplied by n.
connectionTimeoutInMs) Sets the maximum time in milliseconds to wait to acquire a live connection. This includes connecting and authenticating to the database and verifying the connection.
This value is also used as "login timeout" on the underlying SQL driver (if possible).
idleTimeoutInMinutes) Sets the maximum time in minutes a connection is allowed to be idle before it is closed. This setting is useful when a firewall drops idle connections after a while, to proactively close idle connections beforehand.
This setting only applies when "Minimum Idle Connections" is defined to be less than "Maximum Pool Size". Whether a connection is retired as idle or not is subject to a maximum variation of +30 seconds (to avoid retiring many connections at the same time). A connection will never be retired as idle before this timeout. Once the pool reaches "Minimum Idle Connections", connections will no longer be retired, even if idle.
maxLifetimeInMinutes) leakDetectionThresholdInSeconds) transactionIsolationLevel) enableJmx) connectionInitSql) driverClass) The class name of the JDBC driver to use. The driver must be on the class path. This property is required for preloading the correct driver class and for detecting the SQL dialect.
Legacy drivers:
- For Oracle before 9i use oracle.jdbc.driver.OracleDriver.
- For MySQL 5.x use com.mysql.jdbc.Driver.
url) user) password) connectionTestStatement) SQL statement to test the database connection. Only use this property if your connections aren't correctly tested for validity. A JDBC 4.0 driver is usually able to test the connection validity with an internal mechanism, without an explicit test statement.
For H2 databases, a statement involving a table name should be used.
This is database specific and should be set to a query that consumes the minimal amount of load on the server.
sqlDialect) The SQL dialect to use. SQL dialects have minor – but important – differences: For example, Oracle does not support auto-increment, or MSSQL requires extra information for an insert statement with default values.
With the default setting (AUTOMATIC), the dialect is automatically determined based on the "Driver Class" of the JDBC driver. When using a non-standard "Driver Class", the SQL dialect of the underlying database cannot be determined automatically and must be set to the correct value here.
driverProperties)
type: JdbcConnectionPool
id: JdbcConnectionPool-xxxxxx
displayName:
comment:
properties:
connectionInitSql:
connectionTestStatement:
connectionTimeoutInMs: 5000
driverClass:
driverProperties:
enableJmx: false
idleTimeoutInMinutes: 10
leakDetectionThresholdInSeconds: 60
maxLifetimeInMinutes: 30
maximumPoolSize: 20
minimumIdleConnections: 5
password:
sqlDialect: AUTOMATIC
transactionIsolationLevel:
url:
user: