# By Brett Wooldridge (8) and Jared Stehler (2)
# Via Brett Wooldridge (3) and Jared Stehler (2)
* 'dev' of github.com-brettwooldridge:brettwooldridge/HikariCP:
merged
log pool name in warn messages
Update README.md
Update README.md
[maven-release-plugin] prepare for next development iteration
[maven-release-plugin] prepare release HikariCP-1.3.5
Typo
Update README.md
Update README.md
Update README.md
@ -9,7 +9,7 @@ There is nothing faster. There is nothing more correct. HikariCP is a "zero-ov
<dependency>
<dependency>
<groupId>com.zaxxer</groupId>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
<artifactId>HikariCP</artifactId>
<version>1.3.4</version>
<version>1.3.5</version>
<scope>compile</scope>
<scope>compile</scope>
</dependency>
</dependency>
```
```
@ -35,10 +35,13 @@ Using the excellent [JMH microbenchmark framework](http://openjdk.java.net/proje
<sup>2</sup> Tomcat fails to complete *Statement Cycle* benchmark when "StatementFinalizer" feature is enabled.<br/>
<sup>2</sup> Tomcat fails to complete *Statement Cycle* benchmark when "StatementFinalizer" feature is enabled.<br/>
<sup>3</sup> Benchmark results run against 1.3.3<br/>
<sup>3</sup> Benchmark results run against 1.3.3<br/>
#### What's wrong with other pools?
#### What's up with other pools?
Not all pools are created equal. Read our [pool analysis](https://github.com/brettwooldridge/HikariCP/wiki/Pool-Analysis) here if you care to know the good, bad, and ugly.
Not all pools are created equal. Read our [pool analysis](https://github.com/brettwooldridge/HikariCP/wiki/Pool-Analysis) here if you care to know the good, bad, and ugly.
#### You're [probably] doing it wrong.
AKA ["What you probably didn't know about connection pool sizing"](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing). Read on to find out.
------------------------------
------------------------------
#### Configuration (knobs, baby!)
#### Configuration (knobs, baby!)
@ -126,12 +129,12 @@ preferred if supported by the JDBC driver. *Default: true*
:abc:``jdbcUrl``<br/>
:abc:``jdbcUrl``<br/>
This property is only used when the ``driverClassName`` property is used to wrap an old-school
This property is only used when the ``driverClassName`` property is used to wrap an old-school
JDBC driver as a ``javax.sql.DataSource``. While JBDC URLs are popular, HikariCP does not
JDBC driver as a ``javax.sql.DataSource``. While JBDC URLs are popular, HikariCP does not
recommend using them. The *DataSource* implementation for your driver provides bean properties
recommend using them. The *DataSource* implementation provided by your driver provides bean
for all the driver parameters that used to be specified in the JDBC URL. Before using the ``jdbcUrl``
properties for all the driver parameters that used to be specified in the JDBC URL. Before using
and ``driverClassName`` because that's the way you've always done it, consider using the more
the ``jdbcUrl`` and ``driverClassName`` because that's the way you've always done it, consider
modern and maintainable ``dataSourceClassName`` approach instead. Note that if this property
using the more modern and maintainable ``dataSourceClassName`` approach instead. Note that if
is used, you may still use *DataSource* properties to configure your driver and is in fact
this property is used, you may still use *DataSource* properties to configure your driver and
recommended. *Default: none*
is in fact recommended. *Default: none*
:watch:``leakDetectionThreshold``<br/>
:watch:``leakDetectionThreshold``<br/>
This property controls the amount of time that a connection can be out of the pool before a
This property controls the amount of time that a connection can be out of the pool before a
@ -162,7 +165,7 @@ before timing out. *Default: 10*
This property controls the minimum number of *idle connections* that HikariCP tries to maintain
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, HikariCP will make a best effort to
in the pool. If the idle connections dip below this value, HikariCP will make a best effort to
add additional connections quickly and efficiently. However, for maximum performance and
add additional connections quickly and efficiently. However, for maximum performance and
responsiveness to spike demands, we recommend *not* setting this value and instead alloing
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*
HikariCP to act as a *fixed size* connection pool. *Default: same as maximumPoolSize*
The advantage of configuring via ``HikariConfig`` over ``HikariDataSource`` is that when using the ``HikariConfig`` we know at ``DataSource`` construction-time what the configuration is, so the pool can be initialized at that point. However, when using ``HikariDataSource`` alone, we don't know that you are *done* configuring the DataSource until ``getConnection()`` is called. In that case, ``getConnection()`` must perform an additional check to see if the pool has been initialized yet or not. The cost (albeit small) of this check is incurred on every invocation of ``getConnection()`` in that case. In summary, intialization by ``HikariConfig`` is ever so slightly more performant than initialization directly on the ``HikariDataSource`` -- not just at construction time but also at runtime.
The advantage of configuring via ``HikariConfig`` over ``HikariDataSource`` is that when using the ``HikariConfig`` we know at ``DataSource`` construction-time what the configuration is, so the pool can be initialized at that point. However, when using ``HikariDataSource`` alone, we don't know that you are *done* configuring the DataSource until ``getConnection()`` is called. In that case, ``getConnection()`` must perform an additional check to see if the pool has been initialized yet or not. The cost (albeit small) of this check is incurred on every invocation of ``getConnection()`` in that case. In summary, intialization by ``HikariConfig`` is ever so slightly more performant than initialization directly on the ``HikariDataSource`` -- not just at construction time but also at runtime.
### Popular DataSource Class Names
We recommended using ``dataSourceClassName`` instead of ``driverClassName``/``jdbcUrl``, as using the driver class requires HikariCP to wrap the driver with an internal *DataSource* class. Here is a list of JDBC *DataSource* classes for popular databases:
LOGGER.warn("Connection {} marked as broken because of SQLSTATE({}), ErrorCode({}): {}",delegate.toString(),sqlState,sqle.getErrorCode(),sqle.getNextException());
LOGGER.warn("Connection {} ({}) marked as broken because of SQLSTATE({}), ErrorCode({}): {}",delegate.toString(),parentPool.toString(),sqle.getErrorCode(),sqle.getNextException());