c3p0配置 initialPoolSize 和minPoolSize 可以设为0吗?设0有坏处吗?

c3p0配置 initialPoolSize 和minPoolSize 可以设为0吗?设0有坏处吗?

 

c3p0配置  initialPoolSize 和minPoolSize 可以设为0吗?设0有坏处吗?

2015-04-14 11:18
提问者采纳

热心网友

<dependency>			<groupId>c3p0</groupId>			<artifactId>c3p0</artifactId>			<version>0.9.1.2</version>		</dependency>

本文将对sdkservice生产环境上c3p0正在使用的各项配置进行详细解释,旨在为c3p0的配置提供参考标准。sdkservice生成环境的配置如下:#当连接池中的连接耗尽的时候c3p0一次同时获取的连接数。Default: 3c3p0.acquireIncrement=20#初始化时获取连接数,取值应在minPoolSize与maxPoolSize之间。Default: 3  

c3p0.initialPoolSize=20#连接池中保留的最小连接数,默认为:3c3p0.minPoolSize=20#连接池中保留的最大连接数。默认值: 15c3p0.maxPoolSize=100#最大空闲时间,多少秒内未使用则连接被丢弃。若为0则永不丢弃。默认值: 0c3p0.maxIdleTime=60#c3p0全局的PreparedStatements缓存的大小。如果maxStatements与maxStatementsPerConnection均为0,则缓存不生效,只要有一个不为0,则语句的缓存就能生效。如果默认值: 0c3p0.maxStatements=0#c3p0是异步操作的,缓慢的JDBC操作通过帮助进程完成。扩展这些操作可以有效的提升性能通过多线程实现多个操作同时被执行。Default: 3c3p0.numHelperThreads=10#定义在从数据库获取新连接失败后重复尝试的次数。默认值: 30 ;小于等于0表示无限次 

c3p0.acquireRetryAttempts=5#重新尝试的时间间隔,默认为:1000毫秒c3p0.acquireRetryDelay=300#获取一个connection需要的时间,单位毫秒c3p0.checkoutTimeout=3000#每隔多少秒检查所有连接池中的空闲连接。Default: 0 

c3p0. idleConnectionTestPeriod=60#c3p0将建一张名为改配置项的空表,并使用其自带的查询语句进行测试。如果定义了这个参数那么属性preferredTestQuery将#被忽略。你不能在这张Test表上进行任何操作,它将只供c3p0测试使用。默认值: null。由于运营平台的数据库用户没有创建表的权限,故需要发sql创建表。c3p0.automaticTestTable=sys_connectiontest#如果设为true那么在取得连接的同时将校验连接的有效性。Default: falsec3p0.testConnectionOnCheckin=true#一个checkout连接的超时设置,一旦一个checkout连接超时,他将物理的关闭,而不是返回池中,主要是防止连接被长期使用不释放,这个设置也是比较危险的c3p0.unreturnedConnectionTimeout=15

下面分块解释各配置项值的由来。基础连接池配置:maxPoolSize最大连接数在满足应用需要的情况下,参考默认值15,越小越好。由于sdkservice多次出现连接数不够的情况,该值也越改越大。现已改为100。minPoolSize最小连接数需要小于等于最大连接数,参考默认值3,越小越好。同maxPoolSize的原因, 现已改为20。initialPoolSize初始化连接数需要在最大和最小连接数之间,否则会被最小连接数的值替换,参考默认值3。 同maxPoolSize的原因, 现已改为20。acquireIncrement连接耗尽时一次获取的连接数,参考默认值3,由于sdkservice用到的mysql proxy在连接不够进行扩容时,会出现获取连接失败的异常,所以将acquireIncrement的值设置较大,以减少mysql proxy的扩容异常。 maxIdleTime最大空闲时间,该时间内未使用,则丢弃。设置为60秒。
时间: 2024-11-05 15:45:07

c3p0配置 initialPoolSize 和minPoolSize 可以设为0吗?设0有坏处吗?的相关文章

关于c3p0配置详细说明

<!-- c3p0连接池配置 --> <property name="driverClass" value="${c3p0.driverClass}"></property> <property name="jdbcUrl" value="${c3p0.url}"></property> <property name="user" value

c3p0配置详解

数据库连接池C3P0框架是个非常优异的开源jar,高性能的管理着数据源,这里只讨论程序本身负责数据源,不讨论容器管理. 一.实现方式: C3P0有三种方式实现: 1.自己动手写代码,实现数据源 例如:在类路径下配置一个属性文件,config.properties,内容如下: driverClass=xxx jdbcUrl=xxx user=xxx password=xxx ... 然后代码中实现 Properties props = new Properties(); InputStream i

C3P0配置属性的说明

此外C3P0配置属性的说明如下: 当连接池中的连接耗尽的时候c3p0一次同时获取的连接数.Default: 3 --> <property name="acquireIncrement">3</property> <!--定义在从数据库获取新连接失败后重复尝试的次数.Default: 30 --> <property name="acquireRetryAttempts">30</property>

Spring之——c3p0配置详解

转载请注明出处:http://blog.csdn.net/l1028386804/article/details/51162560 今天,我们就来详细谈谈Spring中的c3p0配置问题,好了,不耽搁大家的时间,我们直接进入主题,请看下面的具体配置文件信息: <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/

(转)C3P0配置

C3P0是一个开源的JDBC 连接池,它实现了数据源和JNDI绑定,支持JDBC3规范和JDBC2的标准扩展.目前使用它的开源项目有Hibernate,Spring等. sourceforge 下载: http://sourceforge.net/projects/c3p0/ 一般我们在项目中操作数据库时,都是每次需要操作数据库就建立一个连接,操作完成后释放连接.因为jdbc没有保持连接的能力,一旦超过一定时间没有使用(大约几百毫秒),连接就会被自动释放掉.而每次新建连接都需要140毫秒左右的时

开源JDBC连接池DBCP和C3P0配置(转)

现在Tomcat下使用的是公司框架默认的 Apache DBCP连接池.此种连接池虽出自名门Apache基金会.但口碑不是很好,在新版的Hibernate中已经放弃了对DBCP的支持,取而代之的是 C3P0.开始我还对DBCP抱有希望,加上各种参数设置,但均无效.后来换上了C3P0,使用其testConnectionOnCheckout. testConnectionOnCheckin参数配置后果然一剑封喉的解决了问题.(说明:此种办法其实会带来一定的性能损耗)一.DBCP和C3P0连接池常用配

Tomcat下使用c3p0配置jndi数据源

下载c3p0包: 下载地址:https://sourceforge.net/projects/c3p0/files/?source=navbar 解压后得到包:c3p0-0.9.2.jar,mchange-commons-java-0.2.11.jar 下载mysql包: 下载地址:http://download.csdn.net/download/u010802461/9579306 解压后得到包:mysql-connector-java-5.1.39-bin.jar(笔者这里没有是因为我将包

JNDI学习总结(二)——Tomcat下使用C3P0配置JNDI数据源

一.C3P0下载 C3P0下载地址:http://sourceforge.net/projects/c3p0/files/?source=navbar 下载完成之后得到一个压缩包. 二.使用C3P0配置JNDI数据源 Tomcat6.x中配置JNDI数据源时默认使用的是Tomcat6.x自带的DBCP连接池,Tomcat6.x使用DBCP连接池配置JNDI数据源如下: 1 <Resource 2 name="oracleDataSource" 3 auth="Conta

整合Acitiviti在线流程设计器(Activiti-Modeler 5.18.0)

整合Acitiviti在线流程设计器(Activiti-Modeler 5.18.0) 1.概述前言 一直以来都是从事大量的工作流相关的项目,用过很多商用的工作流产品,包括国内与国外的,尽管商用的工作产品在UI操作上比较人性化,但个人用户觉得,这东西只需要一些初级用户,对于我们一直在为一些高级的客户提供一些专业的数据整合.流程梳理.系统间的数据穿透时,这些系统因为不开源,给项目的实施带来巨大的风险,在一些项目栽过跟头后,我更偏向于使用开源的平台了.但开源平台最大的难点是在于你是否有足够的技术人员