连接池技术和数据库事务文档1031资料.docx
《连接池技术和数据库事务文档1031资料.docx》由会员分享，可在线阅读，更多相关《连接池技术和数据库事务文档1031资料.docx（27页珍藏版）》请在冰豆网上搜索。
连接池技术和数据库事务文档1031资料
连接池和数据库事务的使用
1.文档目的
该文档指导项目开发过程中，关于连接池技术和数据库事务的原理以及他们在项目中使用是如何被使用等问题提供参考。
以便开发人员理解并使用这些技术用于开发项目，减少项目存在的隐患风险以及提高项目开发效率等。
2.连接池技术的应用
2.1.连接池的历史
数据库连接技术或者池化技术应该很早就有了。
1990年JAVA发明的时候，世界上应该就有连接池技术了。
一般为专有技术，但真正大面积使用这个技术应该到90年代末。
2002年8月份开源的dbcp发布，意味着已经可以非常方便安全的使用连接池技术。
2.2.连接池的作用
数据库连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而再不是重新建立一个；释放空闲时间超过最大空闲时间的数据库连接来避免因为没有释放数据库连接而引起的数据库连接遗漏。
这样一来可以大大减小应用程序中频繁创建和销毁连接对象的操作次数，降低服务器端的开销。
这项技术能明显提高对数据库操作的性能。
2.3.连接池的工作原理
建立连接是一个费时的活动，每次都得花费0.05s～1s的时间，而且系统还要分配内存资源。
这个时间对于一次或几次数据库操作，或许感觉不出系统有多大的开销。
可是对于现在的Web应用，尤其是大型电子商务网站，同时有几百人甚至几千人在线是很正常的事。
在这种情况下，频繁的进行数据库连接操作势必占用很多的系统资源，网站的响应速度必定下降，严重的甚至会造成服务器的崩溃。
不是危言耸听，这就是制约某些电子商务网站发展的技术瓶颈问题。
其次，对于每一次数据库连接，使用完后都得断开。
否则，如果程序出现异常而未能关闭，将会导致数据库系统中的内存泄漏，最终将不得不重启数据库。
还有，这种开发不能控制被创建的连接对象数，系统资源会被毫无顾及的分配出去，如连接过多，也可能导致内存泄漏，服务器崩溃。
数据库连接默认只有150个，一般好一点的服务器会配到300个。
所以如果没有正确关闭连接，正式系统上线，只需要几分钟就绝对崩溃了。
这种情况一般不会发生，我们仅讨论一下如果不用连接池，自己每次打开连接并关闭的情况。
随便以一个网站，如12345为例，页面有数据的内容有10块，其至少产生10次查询。
假设进首页的人反应比较慢，他可能需要30秒才能找到自己感兴趣的内容并且点到详细页面。
那么相当于3秒有一次数据库连接的创建。
如果数据库连接耗时平均为0.5秒。
那么这个网站只要900人在线就有可能发生崩溃。
而根据峰值定律。
他只需要180人在线，就有崩溃的危险。
这个崩溃的概率不仅停留在理论上。
我们随便一个正式的应用，都可以轻易突破180人。
结论：
正式项目中任何功能必须使用连接池。
对于共享资源，有一个很著名的设计模式：
资源池（ResourcePool）。
该模式正是为了解决资源的频繁分配﹑释放所造成的问题。
为解决上述问题，可以采用数据库连接池技术。
数据库连接池的基本思想就是为数据库连接建立一个“缓冲池”。
预先在缓冲池中放入一定数量的连接，当需要建立数据库连接时，只需从“缓冲池”中取出一个，使用完毕之后再放回去。
我们可以通过设定连接池最大连接数来防止系统无尽的与数据库连接。
更为重要的是我们可以通过连接池的管理机制监视数据库的连接的数量﹑使用情况，为系统开发﹑测试及性能调整提供依据。
连接池的基本工作原理见下图。
2.4.连接池带来的性能提升和安全性
性能比较（连接耗时——通过不断循环n次获取连接和释放连接）
连接次数
分类
10
20
30
40
50
100
连接池
343ms
345ms
335ms
338ms
336ms
337ms
创建连接
594ms
1165ms
1875ms
2291ms
2895ms
6179ms
安全性
可以控制创建出来的数据库连接数，并管理好这些连接，在某个连接超过最大空闲时间时，连接池可以将这个连接交还给数据库，防止数据的崩溃；若连接数小于最小连接数则新建一个新的连接到连接池中，保证连接池中有最小连接数。
同时还可以防止应用因为无限创建连接造成巨大的资源开销。
2.5.连接池可能有的副作用
（1）连接池的连接数达到最大连接数时，则不能再创建新的连接，需要等待其他连接的释放才能获取到连接。
（2）假如调用的连接没有及时释放回连接池中去，而连接池中没有空闲的连接时，连接池就需要去创建新的连接，当达到最大连接数时，就会发生
（1）的情况，所以在项目开发过程中，要注意及时地将用完结束的连接释放到连接池中去。
（3）使用连接池时，要根据项目需求配置好合理的初始连接数和最大连接数，初始连接数太小，对于高并发的访问空闲连接数不足时需要去创建新的连接，这样换来的代价高。
初始连接数太大，启动初始化时时间比较长，而项目不需要这么多连接，造成资源浪费。
2.6.几种连接池的对比
在项目中有可能用到的开源的连接池主要有DBCP、c3p0、proxool和BoneCP，还有其他的开源连接池还有DDConnectionBroker、DBPoo、XAPool、Primrose、SmartPool等。
下面主要是DBCP、c3p0、proxool和BoneCP这四个开源连接池的比较。
1.DBCP连接池
DBCP可能是使用最多的开源连接池，原因大概是因为配置方便，而且很多开源和tomcat应用例子都是使用的这个连接池吧。
这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
使用评价：
在具体项目应用中，发现此连接池的持续运行的稳定性还是可以，不过速度稍慢，在大并发量的压力下稳定性有所下降，此外不提供连接池监控。
配置：
需要导入的包：
commons-dbcp.jar和commons-pool.jar（或者用tomcat-dbcp.jar一个包就行）以及数据库驱动包（下略。
其中oracle为classes12.jar；mysql为mysql-connector-java-5.0.8-bin.jar等）
applicationContext.xml中配置如下：
--dbcp数据源-->
destroy-method="close">
oracle:
thin:
@127.0.0.1:
1521:
orcl"/>
（主页：
http:
//commons.apache.org/dbcp/）
2.c3p0连接池
c3p0是另外一个开源的连接池，在业界也是比较有名的，这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
使用评价：
在具体项目应用中，发现此连接池的持续运行的稳定性相当不错，在大并发量的压力下稳定性也有一定保证，此外不提供连接池监控。
c3p0有自动回收空闲连接功能，连接池解决了dbcp无法自动重连问题。
配置：
需要导入的包：
c3p0-0.9.1.2.jar（这个包本身导入spring库的时候就已经导入）以及数据库驱动包。
applicationContext.xml中配置如下：
--c3p0数据源-->
destroy-method="close">
value="jdbc:
oracle:
thin:
@127.0.0.1:
1521:
orcl">
（主页：
3.Proxool连接池
Proxool这个连接池可能用到的人比较少，但也有一定知名度，这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
使用评价：
在具体项目应用中，发现此连接池的持续运行的稳定性有一定问题，有一个需要长时间跑批的任务场景任务，同样的代码在其他的开源连接池中成功结束，但在Proxool中出现异常退出。
但是Proxool有一个优势--连接池监控。
配置：
需要导入的包：
proxool-0.9.1.jar和proxool-cglib.jar以及数据库驱动包。
配置方法一：
与其他连接池的配置类似，直接在applicationContext.xml中配置：
--proxool数据源-->
--跟dbcp/c3p0一样单独的配置-->
--连接池配置成功,但这种做法监听没办法起来（可能未配置成功）-->
class="org.logicalcobwebs.proxool.ProxoolDataSource">
value="oracle.jdbc.driver.OracleDriver">
value="jdbc:
oracle:
thin:
@127.0.0.1:
1521:
orcl">
配置方法二：
在WebRoot/WEB-INF下新建一个proxool.xml文件，内容如下：
xmlversion="1.0"encoding="UTF-8"?
>
usernameDb
jdbc:
oracle:
thin:
@127.0.0.1:
1521:
orcl
oracle.jdbc.driver.OracleDriver
30
10
select1fromdual
在web.xml中调用proxool.xml，配置如下：
--引入proxool配置文件-->
proxoolServletConfigurator
org.logicalcobwebs.proxool.configuration.ServletConfigurator
--以xml文件方式引入-->
xmlFile
--xml文件存放目录-->
WEB-INF/proxool.xml
1
在applicationContext.xml中的配置如下：
--与proxool.xml和web.xml里结合使用-->
--连接池配置成功,监听也可以起来-->
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
value="org.logicalcobwebs.proxool.ProxoolDriver">
--proxool.xml文件中proxool结点的别名（alias）为usernameDb-->
由于proxool连接可以对连接池进行监控，在web.xml中配置
proxoolAdmin
org.logicalcobwebs.proxool.admin.servlet.AdminServlet
proxoolAdmin
/proxoolAdmin
通过访问proxoolAdmin即可监控连接池的情况
（主页：
4.BoneCP连接池
BoneCP是一个快速，开源的数据库连接池，可以设置最大和最小连接，连接等待时间等，基本功能都有。
使用评价：
BoneCP连接池帮你管理数据连接让你的应用程序能更快速地访问数据库，比c3p0/DBCP连接池快25倍，并且有自动连接验证和自动重播任何失败的交易的能力（数据库/网络出现故障等情况下），但它的持续运行的稳定性有一定问题。
配置：
需要导入的包：
bonecp-0.7.1-rc1.jar、guava-r07.jar、slf4j-api-1.5.8.jar和slf4j-log4j12-1.5.8.jar（这些包从官网上下载下来的时候是zip压缩包，将拓展名改为jar就可以了）以及数据库驱动包。
applicationContext.xml中配置如下：
--BoneCP数据源-->
destroy-method="close">
value="jdbc:
oracle:
thin:
@127.0.0.1:
1521:
orcl"/>
（主页：
总结:
综上所述，这几种开源连接池各有优劣，看了网络上很多评论，大都推荐使用DBCP和c3p0，经检验这种连接池性能稳定，承压能力强。
而Proxool尽管有明显的性能问题，但由于它具备监控功能，因此建议在开发测试时使用，有助于确定是否有连接没有被关掉，可以排除一些代码的性能问题。
BoneCP拥有很高的性能，但是稳定性有一定问题。
另外，各连接池配置常用的一些参数比较如下（参考网址：
DBCP
c3p0
proxool
boneCP
数据库用户名称
Username
User
username
数据库密码
Password
Password
password
驱动名称
DriverClassName
DriverClass
driver-class
driverClass
Jdbc连接串
Url
JdbcUrl
driver-url
jdbcUrl
初始化大小
InitialSize
InitialPoolSize
连接池最小空闲
MinIdle
MinPoolSize
minimum-connection-count
minConnectionsPerPartition
连接池最大空闲
MaxIdle
连接池最大使用连接数量
MaxActive
MaxPoolSize
maximum-connection-count
maxConnectionsPerPartition
最小逐出时间
MinEvictableIdleTimeMillis
maxIdleTime
house-keeping-sleep-time
获取连接时测试是否有效
TestOnBorrow
TestConnectionOnCheckout
test-before-use
归还连接时是否测试有效
TestOnReturn
TestConnectionOnCheckin
test-after-use
连接空闲时测试是否有效
TestWhileIdle
获取连接最大等待时间
maxWait
性能比较，模拟A个线程循环B次并发访问数据库对比：
（网络参考数据，参考网址：
连接池
并发数
DBCP
c3p0
proxool
boneCP
10A10B
1188ms
953ms
1625ms
63ms
20A10B
1204ms
1000ms
1640ms
110ms
30A10B
1250ms
1047ms
1657ms
156ms
50A10B
1406ms
1343ms
1843ms
172ms
100A10B
1641ms
2703ms
2031ms
532ms
200A10B
2093ms
4891ms
2406ms
936ms
500A10B
3219ms
11703ms
3343ms
1922ms
1000A10B
5187ms
12563ms
4703ms
3610ms
3000A10B
14094ms
16297ms
11344ms
11391ms
5000A10B
23610ms
22032ms
20125ms
17125ms
现在主流的连接池不多，一般选择主流，因为他有很多人共同发现问题，共同调优，并且版本在跟进。
DBCP和C3P0一般是选择最多的。
因为连接池性能本身已经挺高了。
所以如果不是极端情况，并不过分关心性能。
而他们最主要的区别是。
如果某个连接断掉（比如网络不稳定），C3P0会一直等待到超时，如果这期间恢复了连接，他就平滑过渡。
这个特性也不一定就算好事，如果页面访问量大，这个特性可能导致页面等待多了，发生拒绝访问。
根据项目需要选用。
另外hibernate3早期，因为DBCP的BUG而放弃对DBCP的支持。
现在这个BUG应该不需要太过在意。
但是配置的时候，请参考阮杰锋在JIRA上记载的经验。
但如果我们使用专业服务器。
比如weblogic或websphere的时候。
他们自带连接池，而且他们操作图形化，非常方便的调优和监控，往往也能带来便利。
不过这些服务器要钱，只有项目中允许，才能使用。
--数据源-->
oracle:
thin:
@127.0.0.1:
1521:
orcl"/>
升级会员 