要約

HikariCP is a solid high-performance JDBC connection pool. A connection pool is a cache of database connections maintained so that the connections can be reused when future requests to the database are required. Connection pools may significantly reduce the overall resource usage. - You can find out more here. 

Properties 

These are the Atlassian HikariCP configuration properties that are set by default in the bamboo.cfg.xml configuration file.

<property name="hibernate.hikari.idleTimeout">120000</property>
<property name="hibernate.hikari.maximumPoolSize">170</property>
<property name="hibernate.hikari.minimumIdle">3</property> // When minimumIdle is not set it won't limit connections. It will consider the maximumPoolSize already set which is recommended.
<property name="hibernate.hikari.registerMbeans">true</property>

From Bamboo 9.4, the following properties are also added to the default Bamboo configuration file via BAM-22453 - Getting issue details... STATUS . You can also add such properties to prior versions of Bamboo normally.

<property name="hibernate.hikari.connectionTimeout">30000</property>
<property name="hibernate.hikari.leakDetectionThreshold">0</property>

idleTimeout

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 an 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: 120000 (2 minutes)

maximumPoolSize

Controls the maximum size that the pool is allowed to reach, including both idle and in-use connections. 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 HirakiCP's pool sizing. Default: 170

minimumIdle

Controls the minimum number of idle connections that HikariCP tries to maintain in the pool. If the idle connections dip below this value and the total connections in the pool are less than maximumPoolSize, HikariCP will make the 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: 3

registerMbeans

Controls whether or not JMX Management Beans ("MBeans") are registered or not. Default: true

connectionTimeout

Controls the maximum number of milliseconds that Bamboo will wait for a connection from the pool. If this time is exceeded without a connection becoming available, an SQL Exception will be thrown. The lowest acceptable connection timeout is 250 ms. Default: 30000 (30 seconds)

maxLifetime

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. 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)

leakDetectionThreshold

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. The lowest acceptable value for enabling leak detection is 2000 (2 seconds). Default: 0 (disabled)

構成 

According to Hikari Pool Sizing and Github HikariCP:

• HikariPool does expose the number of active connections, but it's only for JMX.
• HikariDataSource doesn't expose any way to get the HikariPool.
• Hikari doesn't offer any type of listener for pool interactions, like trying to track when connections are checked in and out.
• Hikari prefers using a DataSource, per their documentation.
• Some functionality, like statement caching, needs to be configured in the DataSource's properties; Hikari itself doesn't offer that functionality.

Database pooling is now handled by HikariCP for the 4.0 release.

The properties are:

The following settings have been removed without replacement:

• db.pool.acquireIncrement - HikariCP opens connections one at a time, as needed;
• db.pool.cache.statements - HikariCP does not offer statement caching;
• db.pool.idle.testInterval - HikariCP tests connections when they’re leased, not on a timer;
• db.pool.connection.threshold - HikariCP doesn’t have a percentile idle threshold;
• db.pool.size.idle - can be used to keep a fixed number of connections idle;
• db.pool.threads - HikariCP does not use extra threads to “aid” connection release;