core-jgi/org.compiere.db.oracle.prov.../META-INF/pool/server.default.properties

73 lines
4.2 KiB
Properties
Raw Normal View History

IDEMPIERE-5013 Implement HikariCP as a replacement for c3p0 (#926) * Replaced PostgreSQL and Oracle connection pools with HikariCP. Replaced C3P0 with HikariCP. HikariCP is a Apache licensed connection pool with substantially better performance and better resilience to failure (DB disconnects, etc.) then C3P0. Read more about it here: https://github.com/brettwooldridge/HikariCP . Cleaned up the `getCachedConnection` method. With HikariCP there is no need to retry to obtain a connection since getting an connection will block until a free connection is available or until a timeout is reached (default 30 seconds) at which point an `SQLException` is thrown. This also removed calling `Runtime.getRuntime().runFinalization();`. HikariCP is currently configured to detect / log leaks when a connection hasn't returned to the pool for longer then 5 minutes. Loading of pool config properties was cleaned up. Defaults are now loaded from a single file instead of defaults coming from both file and hardcoded properties. It is now also possible to specify any HikariCP property in the user pool property file. Initialization of the datasource must happen in the `getDataSource()` method because at object construction not all JDBC config is known. However this method could (as far as I could tell) be called concurrently from multiple threads but had no mechanism to prevent initializing the DB pool multiple times. The variable in which the pool itself was stored (`m_ds`) also was not marked volatile or immutable which could lead to visibility issues. Instead of lazy initialization of the pool in the `getDataSource()` method the pool could probably better be initialized at object construction. However I wasn't able to achieve that without breakage therefor I made the initialization mechanism work correctly with concurrent invocations. Various config options such as the `MaxStatementsPerConnection` options were removed because HikariCP doesn't support them. * (Re)added Sequence time-out.
2022-09-10 17:21:57 +07:00
# !! ALL SETTINGS PRESENT IN THIS FILE WILL BE FED IN TO HIKARICP !!
# !! DO NOT SET EMPTY VALUES !!
#
# You can add HikariCP settings that are not present in this file. In order to
# use the default just remove or comment out the key all together.
IDEMPIERE-5013 Implement HikariCP as a replacement for c3p0 (#926) * Replaced PostgreSQL and Oracle connection pools with HikariCP. Replaced C3P0 with HikariCP. HikariCP is a Apache licensed connection pool with substantially better performance and better resilience to failure (DB disconnects, etc.) then C3P0. Read more about it here: https://github.com/brettwooldridge/HikariCP . Cleaned up the `getCachedConnection` method. With HikariCP there is no need to retry to obtain a connection since getting an connection will block until a free connection is available or until a timeout is reached (default 30 seconds) at which point an `SQLException` is thrown. This also removed calling `Runtime.getRuntime().runFinalization();`. HikariCP is currently configured to detect / log leaks when a connection hasn't returned to the pool for longer then 5 minutes. Loading of pool config properties was cleaned up. Defaults are now loaded from a single file instead of defaults coming from both file and hardcoded properties. It is now also possible to specify any HikariCP property in the user pool property file. Initialization of the datasource must happen in the `getDataSource()` method because at object construction not all JDBC config is known. However this method could (as far as I could tell) be called concurrently from multiple threads but had no mechanism to prevent initializing the DB pool multiple times. The variable in which the pool itself was stored (`m_ds`) also was not marked volatile or immutable which could lead to visibility issues. Instead of lazy initialization of the pool in the `getDataSource()` method the pool could probably better be initialized at object construction. However I wasn't able to achieve that without breakage therefor I made the initialization mechanism work correctly with concurrent invocations. Various config options such as the `MaxStatementsPerConnection` options were removed because HikariCP doesn't support them. * (Re)added Sequence time-out.
2022-09-10 17:21:57 +07:00
# This property controls the maximum number of milliseconds that a client (that's you)
# will wait for a connection from the pool. If this time is exceeded without a
# connection becoming available, a SQLException will be thrown. Lowest acceptable
# connection timeout is 250 ms.
# Default: 30000 (30 seconds)
connectionTimeout=60000
IDEMPIERE-5013 Implement HikariCP as a replacement for c3p0 (#926) * Replaced PostgreSQL and Oracle connection pools with HikariCP. Replaced C3P0 with HikariCP. HikariCP is a Apache licensed connection pool with substantially better performance and better resilience to failure (DB disconnects, etc.) then C3P0. Read more about it here: https://github.com/brettwooldridge/HikariCP . Cleaned up the `getCachedConnection` method. With HikariCP there is no need to retry to obtain a connection since getting an connection will block until a free connection is available or until a timeout is reached (default 30 seconds) at which point an `SQLException` is thrown. This also removed calling `Runtime.getRuntime().runFinalization();`. HikariCP is currently configured to detect / log leaks when a connection hasn't returned to the pool for longer then 5 minutes. Loading of pool config properties was cleaned up. Defaults are now loaded from a single file instead of defaults coming from both file and hardcoded properties. It is now also possible to specify any HikariCP property in the user pool property file. Initialization of the datasource must happen in the `getDataSource()` method because at object construction not all JDBC config is known. However this method could (as far as I could tell) be called concurrently from multiple threads but had no mechanism to prevent initializing the DB pool multiple times. The variable in which the pool itself was stored (`m_ds`) also was not marked volatile or immutable which could lead to visibility issues. Instead of lazy initialization of the pool in the `getDataSource()` method the pool could probably better be initialized at object construction. However I wasn't able to achieve that without breakage therefor I made the initialization mechanism work correctly with concurrent invocations. Various config options such as the `MaxStatementsPerConnection` options were removed because HikariCP doesn't support them. * (Re)added Sequence time-out.
2022-09-10 17:21:57 +07:00
# This property controls the maximum amount of time that a connection is allowed
# to sit idle in the pool. This setting only applies when minimumIdle is defined
# to be less than maximumPoolSize. Idle connections will not be retired once the
# pool reaches minimumIdle connections. Whether a connection is retired as idle
# or not is subject to a maximum variation of +30 seconds, and average variation
# of +15 seconds. A connection will never be retired as idle before this timeout.
# A value of 0 means that idle connections are never removed from the pool.
# The minimum allowed value is 10000ms (10 seconds).
# Default: 600000 (10 minutes)
#idleTimeout=
# This property controls how frequently HikariCP will attempt to keep a connection
# alive, in order to prevent it from being timed out by the database or network infrastructure.
# This value must be less than the maxLifetime value. A "keepalive" will only occur on an idle
# connection. When the time arrives for a "keepalive" against a given connection, that
# connection will be removed from the pool, "pinged", and then returned to the pool. The
# 'ping' is one of either: invocation of the JDBC4 isValid() method, or execution of the
# connectionTestQuery. Typically, the duration out-of-the-pool should be measured in single
# digit milliseconds or even sub-millisecond, and therefore should have little or no noticible
# performance impact. The minimum allowed value is 30000ms (30 seconds), but a value in the
# range of minutes is most desirable. Default: 0 (disabled)
#keepaliveTime=
# This property controls the minimum number of idle connections that HikariCP
# tries to maintain in the pool. If the idle connections dip below this value
# and total connections in the pool are less than maximumPoolSize, HikariCP
# will make a best effort to add additional connections quickly and efficiently.
# However, for maximum performance and responsiveness to spike demands, we
# recommend not setting this value and instead allowing HikariCP to act as a
# fixed size connection pool.
# Default: same as maximumPoolSize
#minimumIdle=
# This property controls the maximum size that the pool is allowed to reach,
# including both idle and in-use connections. Basically this value will determine
# the maximum number of actual connections to the database backend. A reasonable
# value for this is best determined by your execution environment. When the pool
# reaches this size, and no idle connections are available, calls to getConnection()
# will block for up to connectionTimeout milliseconds before timing out. Please
# read about pool sizing: https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
# Default: 10
maximumPoolSize=90
IDEMPIERE-5013 Implement HikariCP as a replacement for c3p0 (#926) * Replaced PostgreSQL and Oracle connection pools with HikariCP. Replaced C3P0 with HikariCP. HikariCP is a Apache licensed connection pool with substantially better performance and better resilience to failure (DB disconnects, etc.) then C3P0. Read more about it here: https://github.com/brettwooldridge/HikariCP . Cleaned up the `getCachedConnection` method. With HikariCP there is no need to retry to obtain a connection since getting an connection will block until a free connection is available or until a timeout is reached (default 30 seconds) at which point an `SQLException` is thrown. This also removed calling `Runtime.getRuntime().runFinalization();`. HikariCP is currently configured to detect / log leaks when a connection hasn't returned to the pool for longer then 5 minutes. Loading of pool config properties was cleaned up. Defaults are now loaded from a single file instead of defaults coming from both file and hardcoded properties. It is now also possible to specify any HikariCP property in the user pool property file. Initialization of the datasource must happen in the `getDataSource()` method because at object construction not all JDBC config is known. However this method could (as far as I could tell) be called concurrently from multiple threads but had no mechanism to prevent initializing the DB pool multiple times. The variable in which the pool itself was stored (`m_ds`) also was not marked volatile or immutable which could lead to visibility issues. Instead of lazy initialization of the pool in the `getDataSource()` method the pool could probably better be initialized at object construction. However I wasn't able to achieve that without breakage therefor I made the initialization mechanism work correctly with concurrent invocations. Various config options such as the `MaxStatementsPerConnection` options were removed because HikariCP doesn't support them. * (Re)added Sequence time-out.
2022-09-10 17:21:57 +07:00
# This property controls the maximum lifetime of a connection in the pool. An
# in-use connection will never be retired, only when it is closed will it then be
# removed. On a connection-by-connection basis, minor negative attenuation is applied
# to avoid mass-extinction in the pool. We strongly recommend setting this value, and
# it should be several seconds shorter than any database or infrastructure imposed
# connection time limit. A value of 0 indicates no maximum lifetime (infinite lifetime),
# subject of course to the idleTimeout setting. The minimum allowed value is 30000ms
# (30 seconds).
# Default: 1800000 (30 minutes)
#maxLifetime=
# This property controls the amount of time that a connection can be out of the
# pool before a message is logged indicating a possible connection leak. A value of 0
# means leak detection is disabled. Lowest acceptable value for enabling leak detection
# is 2000 (2 seconds). Default: 0
leakDetectionThreshold=300000