From 04fbcd27cb919c0aa2b51000ea54e0d49e412f1b Mon Sep 17 00:00:00 2001 From: Brett Wooldridge Date: Thu, 27 Mar 2014 09:51:15 +0900 Subject: [PATCH] Updated examples --- README.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 7d2b020e..3ab66dfc 100644 --- a/README.md +++ b/README.md @@ -239,8 +239,6 @@ HikariDataSource ds = new HikariDataSource(config); ``` Example property file: ```ini -acquireIncrement=3 -acquireRetryDelay=1000 connectionTestQuery=SELECT 1 dataSourceClassName=org.postgresql.ds.PGSimpleDataSource dataSource.user=test @@ -251,7 +249,6 @@ dataSource.serverName=localhost or ``java.util.Properties`` based: ```java Properties props = new Properties(); -props.setProperty("maximumPoolSize", 100); props.setProperty("dataSourceClassName", "org.postgresql.ds.PGSimpleDataSource"); props.setProperty("dataSource.user", "test"); props.setProperty("dataSource.password", "test"); @@ -266,14 +263,14 @@ HikariDataSource ds = new HikariDataSource(config); Finally, you can skip the HikariConfig class altogether and configure the ``HikariDataSource`` directly: ```java HikariDataSource ds = new HikariDataSource(); -ds.setMaximumPoolSize(100); +ds.setMaximumPoolSize(15); ds.setDataSourceClassName("com.mysql.jdbc.jdbc2.optional.MysqlDataSource"); ds.addDataSourceProperty("serverName", "localhost"); ds.addDataSourceProperty("databaseName", "mydb"); ds.addDataSourceProperty("user", "bart"); ds.addDataSourceProperty("password", "51mp50n"); ``` -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 as 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 every 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. ### Play Framework Plugin