Java使用commons-dbcp2.0.1参数配置

1.关于commons-pool及commons-dbcp版本区别

之前项目一直用的是commons-dbcp1.4，因为项目中原来用的是jedis-2.1.0.jar，升级到jedis-2.5.1.jar之后，jedis内部所用的池依赖由原来的commons-pool-1.6.jar改为了commons-pool2-2.2.jar，其中原有的一些参数都改名或删掉了。由于jedis和commons-dbcp内部都是用的commons-pool中的池，所以参数可以也需要按照 commons-pool的实现类来进行配置。

commons-pool1.6和 commons-pool2.2分属 commons-pool中两个不同的大版本，按照 commons-pool官网上的介绍，Apache Commons Pool 2.2 (Java 6.0+)，Apache Commons Pool 1.6 (Java 5.0+)，即不同版本要求的JDK最低版本不同。不同版本升级迁移时注意事项参见：

http://commons.apache.org/proper/commons-pool/

Migrating from Pool 2.x to Pool 2.y

Client code that uses a Pool 2.x release should require no code changes to work with a later Pool 2.x release.

 

New Pool 2.x releases may include support for new configuration attributes. These will be listed in the change log. Note that the MBean interfaces (those with names ending in MXBean or MBean) such as DefaultPooledObjectInfoMBean, GenericKeyedObjectPoolMXBean or GenericKeyedObjectPoolMXBean may change from one release to the next to support these new attributes. These interfaces should, therefore, not be implemented by client as the changes will not be backwards compatible.

 

Migrating from Pool 1.x to Pool 2.x

The migration from Apache Commons Pool 1.x to 2.x will require some code changes. The most significant changes are the changes in package name from org.apache.commons.pool to org.apache.commons.pool2 and the change in the implementation classes to use PooledObjectFactorys, as described above.

 

The key implementation classes (GenericObjectPool and GenericKeyedObjectPool) have retained their names so no changes should be required there although a number of attributes have been renamed to improve consistency and ensure attributes with the same name in different pools have the same meaning. It is likely that some changes will be required to use the new attribute names.

 

而 commons-dbcp现在分成了3个大版本，不同的版本要求的JDK不同：

DBCP now comes in three different versions to support different versions of JDBC. Here is how it works:

DBCP 2 compiles and runs under Java 7 only (JDBC 4.1)

DBCP 1.4 compiles and runs under Java 6 only (JDBC 4)

DBCP 1.3 compiles and runs under Java 1.4-5 only (JDBC 3)

DBCP 2 binaries should be used by applications running under Java 7.

DBCP 1.4 binaries should be used by applications running under Java 6.

DBCP 1.3 should be used when running under Java 1.4 5.

2.关于 commons-dbcp2参数配置

由于commons-dbcp所用的连接池出现版本升级，因此commons-dbcp2中的数据库池连接配置也发生了变化，具体的参数配置说明如下：

---

Parameter	Description
username	The connection username to be passed to our JDBC driver to establish a connection.
password	The connection password to be passed to our JDBC driver to establish a connection.
url	The connection URL to be passed to our JDBC driver to establish a connection.
driverClassName	The fully qualified Java class name of the JDBC driver to be used.
connectionProperties	The connection properties that will be sent to our JDBC driver when establishing new connections.  Format of the string must be [propertyName=property;]*  NOTE - The "user" and "password" properties will be passed explicitly, so they do not need to be included here.

---

Parameter	Default	Description
defaultAutoCommit	driver default	The default auto-commit state of connections created by this pool. If not set then the setAutoCommit method will not be called.
defaultReadOnly	driver default	The default read-only state of connections created by this pool. If not set then the setReadOnly method will not be called. (Some drivers don't support read only mode, ex: Informix)
defaultTransactionIsolation	driver default	The default TransactionIsolation state of connections created by this pool. One of the following: (see javadoc) NONE READ_COMMITTED READ_UNCOMMITTED REPEATABLE_READ SERIALIZABLE
defaultCatalog		The default catalog of connections created by this pool.
cacheState	true	If true, the pooled connection will cache the current readOnly and autoCommit settings when first read or written and on all subsequent writes. This removes the need for additional database queries for any further calls to the getter. If the underlying connection is accessed directly and the readOnly and/or autoCommit settings changed the cached values will not reflect the current state. In this case, caching should be disabled by setting this attribute to false.

---

Parameter	Default	Description
initialSize	0	The initial number of connections that are created when the pool is started.  Since: 1.2
maxTotal	8	The maximum number of active connections that can be allocated from this pool at the same time, or negative for no limit.
maxIdle	8	The maximum number of connections that can remain idle in the pool, without extra ones being released, or negative for no limit.
minIdle	0	The minimum number of connections that can remain idle in the pool, without extra ones being created, or zero to create none.
maxWaitMillis	indefinitely	The maximum number of milliseconds that the pool will wait (when there are no available connections) for a connection to be returned before throwing an exception, or -1 to wait indefinitely.

 NOTE: If maxIdle is set too low on heavily loaded systems it is possible you will see connections being closed and almost immediately new connections being opened. This is a result of the active threads momentarily closing connections faster than they are opening them, causing the number of idle connections to rise above maxIdle. The best value for maxIdle for heavily loaded system will vary but the default is a good starting point.

---

Parameter	Default	Description
validationQuery		The SQL query that will be used to validate connections from this pool before returning them to the caller. If specified, this query MUST be an SQL SELECT statement that returns at least one row. If not specified, connections will be validation by calling the isValid() method.
testOnCreate	false	The indication of whether objects will be validated after creation. If the object fails to validate, the borrow attempt that triggered the object creation will fail.
testOnBorrow	true	The indication of whether objects will be validated before being borrowed from the pool. If the object fails to validate, it will be dropped from the pool, and we will attempt to borrow another.
testOnReturn	false	The indication of whether objects will be validated before being returned to the pool.
testWhileIdle	false	The indication of whether objects will be validated by the idle object evictor (if any). If an object fails to validate, it will be dropped from the pool.
timeBetweenEvictionRunsMillis	-1	The number of milliseconds to sleep between runs of the idle object evictor thread. When non-positive, no idle object evictor thread will be run.
numTestsPerEvictionRun	3	The number of objects to examine during each run of the idle object evictor thread (if any).
minEvictableIdleTimeMillis	1000 * 60 * 30	The minimum amount of time an object may sit idle in the pool before it is eligable for eviction by the idle object evictor (if any).
softMiniEvictableIdleTimeMillis	-1	The minimum amount of time a connection may sit idle in the pool before it is eligible for eviction by the idle connection evictor, with the extra condition that at least "minIdle" connections remain in the pool. When miniEvictableIdleTimeMillis is set to a positive value, miniEvictableIdleTimeMillis is examined first by the idle connection evictor - i.e. when idle connections are visited by the evictor, idle time is first compared against miniEvictableIdleTimeMillis (without considering the number of idle connections in the pool) and then against softMinEvictableIdleTimeMillis, including the minIdle constraint.
maxConnLifetimeMillis	-1	The maximum lifetime in milliseconds of a connection. After this time is exceeded the connection will fail the next activation, passivation or validation test. A value of zero or less means the connection has an infinite lifetime.
connectionInitSqls	null	A Collection of SQL statements that will be used to initialize physical connections when they are first created. These statements are executed only once - when the configured connection factory creates the connection.
lifo	true	True means that borrowObject returns the most recently used ("last in") connection in the pool (if there are idle connections available). False means that the pool behaves as a FIFO queue - connections are taken from the idle instance pool in the order that they are returned to the pool.

---

Parameter	Default	Description
poolPreparedStatements	false	Enable prepared statement pooling for this pool.
maxOpenPreparedStatements	unlimited	The maximum number of open statements that can be allocated from the statement pool at the same time, or negative for no limit.

 This component has also the ability to pool PreparedStatements. When enabled a statement pool will be created for each Connection and PreparedStatements created by one of the following methods will be pooled:

• public PreparedStatement prepareStatement(String sql)
• public PreparedStatement prepareStatement(String sql, int resultSetType, int resultSetConcurrency)

 NOTE - Make sure your connection has some resources left for the other statements. Pooling PreparedStatements may keep their cursors open in the database, causing a connection to run out of cursors, especially if maxOpenPreparedStatements is left at the default (unlimited) and an application opens a large number of different PreparedStatements per connection. To avoid this problem, maxOpenPreparedStatements should be set to a value less than the maximum number of cursors that can be open on a Connection.

---

Parameter	Default	Description
accessToUnderlyingConnectionAllowed	false	Controls if the PoolGuard allows access to the underlying connection.

When allowed you can access the underlying connection using the following construct:

    Connection conn = ds.getConnection();
    Connection dconn =((DelegatingConnection) conn).getInnermostDelegate();
    ...
    conn.close()

 Default is false, it is a potential dangerous operation and misbehaving programs can do harmfull things. (closing the underlying or continue using it when the guarded connection is already closed) Be carefull and only use when you need direct access to driver specific extentions.

 NOTE: Do not close the underlying connection, only the original one.

---

Parameter	Default	Description
removeAbandoned	false	Flag to remove abandoned connections if they exceed the removeAbandonedTimout. If set to true a connection is considered abandoned and eligible for removal if it has not been used for longer than the removeAbandonedTimeout. Creating a Statement, PreparedStatement or CallableStatement or using one of these to execute a query (using one of the execute methods) resets the lastUsed property of the parent connection. Setting this to true can recover db connections from poorly written applications which fail to close a connection.
removeAbandonedTimeout	300	Timeout in seconds before an abandoned connection can be removed.
logAbandoned	false	Flag to log stack traces for application code which abandoned a Statement or Connection. Logging of abandoned Statements and Connections adds overhead for every Connection open or new Statement because a stack trace has to be generated.

 If you have enabled "removeAbandoned" then it is possible that a connection is reclaimed by the pool because it is considered to be abandoned. This mechanism is triggered when (getNumIdle() < 2) and (getNumActive() > getMaxTotal() - 3)

 For example, maxTotal=20 and 18 active connections and 1 idle connection would trigger the "removeAbandoned". But only the active connections that aren't used for more then "removeAbandonedTimeout" seconds are removed, default (300 sec). Traversing a resultset doesn't count as being used. Creating a Statement, PreparedStatement or CallableStatement or using one of these to execute a query (using one of the execute methods) resets the lastUsed property of the parent connection.