首页 > 代码库 > Java框架数据库连接池比较 [转贴 2010-3-20 9:57:51]
Java框架数据库连接池比较 [转贴 2010-3-20 9:57:51]
现在常用的开源数据连接池主要有c3p0,dbcp和proxool三种,其中: ¨hibernate开发组推荐使用c3p0; ¨spring开发组推荐使用dbcp (dbcp连接池有weblogic连接池同样的问题,就是强行关闭连接或数据库重启后,无法reconnect ,告诉连接被重置,这个设置可以解决); ¨hibernate in action推荐使用c3p0和proxool; 下面具体就每种连接池的调研结果进行说明: 1. Apache-DBCP? BasicDataSource 相关的参数说明
? 在使用DBCP的时候,如果使用默认值,则数据库连接因为某种原因断掉后,再从连接池中取得连接又不进行验证,这时取得的连接实际上就会是无效的数据库连接。因此为了防止获得的数据库连接失效,在使用的时候最好保证:
? PS:在构造GenericObjectPool [BasicDataSource在其createDataSource () 方法中也会使用GenericObjectPool] 时,会生成一个内嵌类Evictor,实现自Runnable接口。如果timeBetweenEvictionRunsMillis大于0,每过timeBetweenEvictionRunsMillis毫秒Evictor会调用evict()方法,检查对象的闲置时间是否大于 minEvictableIdleTimeMillis毫秒(_minEvictableIdleTimeMillis小于等于0时则忽略,默认为30分钟),是则销毁此对象,否则就激活并校验对象,然后调用ensureMinIdle方法检查确保池中对象个数不小于_minIdle。在调用returnObject方法把对象放回对象池,首先检查该对象是否有效,然后调用PoolableObjectFactory 的passivateObject方法使对象处于非活动状态。再检查对象池中对象个数是否小于maxIdle,是则可以把此对象放回对象池,否则销毁此对象 ? 上述特性的可设置性已在代码中验证,具体性能是否能实现有待实际验证 2. C3P0? C3P0的官方example中使用的数据源为ComboPooledDataSource,网上一篇文章详细介绍了C3P0连接池配置中各项含义[这些配置项的含义在下载解压c3p0的压缩包之后目录的doc\index.html中的Configuration部分也有详细的介绍,这里偷下懒:P],现摘录如下: <c3p0-config> <property name="automaticTestTable">con_test</property> ? 上述特性的可设置性已在代码中验证,具体性能是否能实现有待实际验证 ? 从配置项的内容来看,C3P0和DBCP都有比较详细的有关连接检测保证的配置,我们可以看到C3P0可以控制数据源内加载的PreparedStatements数量,并且可以设置帮助线程的数量来提升JDBC操作的速度,这些是DBCP未提供的;另外从网络上的评价来看,DBCP出现Bug的频率要大于C3P0,不过这一点有待于我们自己实际的检测。 |
3. Proxool? Proxool的使用和dbcp以及c3p0稍有不同,我们需要并且只需要在使用基本的java.sql.DriverManager之前加载org.logicalcobwebs.proxool.ProxoolDriver驱动类,并且按照proxool定义的url格式 ["proxool." + alias + ":" + driverClass + ":" + driverUrl ,其中alias是为连接池自定义的别名] 来获得connection;具体的可以参看proxool doc下的UserGuide,或本文所附的示例代码。下面对连接池的特性配置作详细说明 [这个是自己翻译的,不一定准确,有问题时请参看doc下的Properties ~]。 n fatal-sql-exception 以逗号隔开的异常列表,当设置了此项之后,每当出现SQLException时都将与列表中异常项作比较,如果匹配则认为出现fatal异常,这将导致connection被丢弃,并且不论出现任何情况该异常将被重抛一次以通知用户发生的情况。默认值为null n fatal-sql-exception-wrapper-class 如果配置了fatal-sql-exception,则默认的操作是丢弃引起SQLException的原因而只是抛出原始异常。使用fatal-sql-exception-wrapper-class这个特性可以将SQLException包装到继承SQLException或RunTimeException的任何异常类里。Proxool提供了两个类供使用FatalSQLException和FatalRunTimeException;使用这两个类的话就将该选项设置为‘org.logicalcobwebs.proxool.FatalSQLException‘或者‘org.logicalcobwebs.proxool.FatalRuntimeException‘。默认值为null n house-keeping-sleep-time proxool自动侦察各个连接状态的时间间隔(毫秒),侦察到空闲的连接就马上回收,超时的销毁,默认值为30秒 n house-keeping-test-sql 如果侦察线程发现闲置连接,则会使用这个SQL语句来对这些连接进行检查;这项设置的语句应该能够被很快的执行,例如查询当前时间 [info.setProperty("proxool.house-keeping-test-sql", "select CURRENT_DATE");] 。如果不设置则该选项被忽略 n injectable-connection-interface、injectable-statement-interface、injectable-prepared-statement-interface、injectable-callable-statement-interface n jmx 如果此项设为true,则连接池将被以名称"Proxool:type=Pool, name=<alias>"注册为JMS Server的MBean。默认值为false n jmx-agent-id 当且仅当jmx选项设为true时使用,为以逗号分隔的连接持注册到的JMS代理名称列表;如果不设置则所有注册的JMX Server都将被使用 n maximum-active-time 线程最大存活时间,超过此时间的线程将被守护线程kill掉,默认值为5分钟 n maximum-connection-count 到数据库的最大连接数,超过了这个连接,再有请求时,就排在队列中等候,最大的等待请求数由simultaneous-build-throttle决定;默认值为15 n maximum-connection-lifetime 连接最大存活时间,毫秒为单位,默认值为4小时 n minimum-connection-count 不管是否被使用都保持开放的最小连接数,默认值为5 n overload-without-refusal-lifetime 用来判断连接池状态,如果在此选项设置时间内(毫秒为单位)拒绝了连接,则认为过负载。默认值为60秒 n prototype-count 最少保持的空闲连接数,注意与minimum-connection-count区分。默认值为0 n simultaneous-build-throttle 最大的等待请求数,默认值为10 n test-before-use 如果设为true则connection在使用前将以house-keeping-test-sql设置的语句测试,如果测试不通过则该connection被丢弃并会重新分配一个connection。默认为false n test-after-use 如果设为true则connection在关闭(放回连接池)前将以house-keeping-test-sql设置的语句测试,如果测试不通过connection将被丢弃。默认值为false ? 与其它连接池特性的设置方法不同,Proxool不提供相应的set方法,所有特性都要以诸如info.setProperty("proxool.jmx", "false");方式设定 ? 上述特性的可设置性已在代码中验证,具体性能是否能实现有待实际验证 ? Proxool与DBCP以及C3P0的性能比较,网上众说纷纭,有待我们自己的测试;其中http://www.oioj.net/blog/user1/2853/archives/2006/298381.shtml 这篇文章对proxool和DBCP做了性能评测,其方法值得我们测试借鉴 |