DBCP connection pool parameters

 

DBCP connection pool parameters

dbcp:
driverClassName
url
username
password The
above four are the driver, connection string, username and password

maxActive Maximum number of connections supported by the
connection pool maxIdle Maximum free maxIdle connections
in the connection pool minIdle Minimum free maxIdle connections in the connection pool
initialSize Initialize the connection Number
maxWait When the connection in the connection pool is used up, the new request wait time, milliseconds
timeBetweenEvictionRunsMillis timeBetweenEvictionRunsMillis is used together with minEvictableIdleTimeMillis, every

timeBetweenEvictionRunsMillis milliseconds check the idle connections in the connection pool, and disconnect the connections whose idle time exceeds minEvictableIdleTimeMillis milliseconds until the connection is made The number of connections in the pool is up to minIdle minEvictableIdleTimeMillis


The time when the connection in the connection pool can be idle, milliseconds

removeAbandoned true, false, whether to clean up the active connections that are not used in removeAbandonedTimeout seconds, and not put back into the connection pool after cleaning
removeAbandonedTimeout The maximum idle time of active connections
logAbandoned true, false, whether to print a message when the connection pool reclaims idle active connections


The two parameters minEvictableIdleTimeMillis and removeAbandonedTimeout are for different connection objects, minEvictableIdleTimeMillis is for connection objects in the connection pool, and removeAbandonedTimeout is for active connections that have not been closed.

 

When configuring, the main difficult to understand are: removeAbandoned, logAbandoned, removeAbandonedTimeout, maxWait these four parameters, set rmoveAbandoned=true, then when getNumActive() is about to getMaxActive(), the system will recycle invalid connections. The recovered Connection is the Connection that is not used after the number of seconds set in removeAbandonedTimeout (default 300 seconds), and the activation recovery mechanism seems to be getNumActive()=getMaxActive()-2. :) If logAbandoned=true, the error message of reclaiming Connection will be printed in the log after the event is reclaimed, including where the Connection was used but forgot to close, which is very useful when debugging.
  Here, it is suggested that the maxWait time should not be set too long. If maxWait is set too long, the client will wait for a long time before triggering the recycling event.
  The properties file for the following configuration: #Connection
settings
jdbc.driverClassName=oracle.jdbc.driver.OracleDriver
jdbc.url=jdbc:oracle:thin:@127.0.0.1:1521:DBSERVER
jdbc.username=user
jdbc.password=pass

#<!-- 初始化连接 -->
dataSource.initialSize=10

#<!-- 最大空闲连接 -->
dataSource.maxIdle=20

#<!-- 最小空闲连接 -->
dataSource.minIdle=5

#最大连接数量
dataSource.maxActive=50

#是否在自动回收超时连接的时候打印连接的超时错误
dataSource.logAbandoned=true

#是否自动回收超时连接
dataSource.removeAbandoned=true

#超时时间(以秒数为单位)
#设置超时时间有一个要注意的地方,超时时间=现在的时间-程序中创建Connection的时间,如果maxActive比较大,比如超过100,那么removeAbandonedTimeout可以设置长一点比如180,也就是三分钟无响应的连接进行回收,当然应用的不同设置长度也不同。
dataSource.removeAbandonedTimeout=180

#<!-- 超时等待时间以毫秒为单位 -->
#maxWait代表当Connection用尽了,多久之后进行回收丢失连接
dataSource.maxWait=1000

 

+
+

+

=

=

=

 

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326840038&siteId=291194637