引言
前提：项目组里无用到SPRING进行事务的治理。项目里以功能划分到每个人手里，
形成了BO，DAO，ACTION，VIEW都是单人负责。在DAO中每个动作都以
封闭式的形式存在。
问题：造成事务的不连贯性。功能是做出来了，性能问题迟早暴露。
测试：主要针对程序频繁请求数据库连接对WEB应用所造成影响做一个测试。
先做必要的说明，一步步引入正题，先从性能瓶颈开始：
性能瓶颈
所有的应用程序都存在性能瓶颈，为了提高应用程序的性能，就要尽可能的减少程序的瓶颈。以下是在java程序中经常存在的性能瓶颈。
了解了这些瓶颈后，就可以有针对性的减少这些瓶颈，从而提高JAVA应用程序的性能
数据库连接池工作原理
关于连接池的实现原理测试方案：
经过资料的收集与APACHE DBCP里连接池的查阅，对现有的连接池工作原理有两种方式：
1. 数据库预先设置配置好的连接数。待得到用户请求连接，传出一个连接，而后为了保持供给数再提前创建连接，即提前预备连接数供请求。比如：
有5个通行道代表最大激活的连接数，最小2个闲置连接数。也就是说连接池里始终预备了2个可随时提供的连接，连接的创建开销是比较大的，连接池的存在就是了能够最小化的解决创建所等待的时间。
1 O
2 O
3 *
4 *
5 *
如上图，当1分配出去时由于池中连接数剩一个，为保持最小闲置，会自动创建一个新的连接以防止再次请求等待创建的时间。这样确实减少了等待的时间，但是数据库创建的开销方面并未得到解决。假如把1-5比喻成汽车，那么这种情况下每量车都是一次性使用。1被请求后下一个连接将是6来接替。那么如何能够重复利用1减少数据库开销。于是引出第二种方式。
2. 回收使用完后的连接，放回到池中进行循环利用。这么做必须能保证2点
一. 使连接能够保持有效的回收。
二. 约束使用者使用释放的动作，而不是直接把连接close.
笔者使用的是APACHE DBCP里BasicDataSource的连接池基本实现，
经过代码与测试结果显示，其工作方式是基于二的。
BasicDataSource测试用例
下面展示了一个测试用例
测试结果：
第2组数据:
并发应用数：100 模拟连接数：6
运行平均耗时：2956
共使用51个连接
运行平均耗时：3391
2共使用52个连接
运行平均耗时：2616
共使用47个连接
运行平均耗时：3377
共使用41个连接
运行平均耗时：3673
共使用46个连接
第2组数据共执行5次;平均耗时为：3229毫秒
平均使用47个连接
第3组数据:
并发应用数：85 模拟连接数：9
运行平均耗时：4830
共使用53个连接
运行平均耗时：3247
共使用49个连接
运行平均耗时：4116
共使用40个连接
运行平均耗时：4070
共使用43个连接
运行平均耗时：4053
共使用54个连接
第3组数据共执行5次;平均耗时为：4063毫秒
平均使用47个连接
第4组数据:
并发应用数：140 模拟连接数：3
运行平均耗时：2076
共使用47个连接
运行平均耗时：3104
共使用51个连接
运行平均耗时：2048
共使用43个连接
运行平均耗时：2421
共使用50个连接
运行平均耗时：2751
共使用50个连接
第4组数据共执行5次;平均耗时为：2480毫秒
平均使用48个连接
每次测试的结果都可能不同，但是所得到的结论是一致的。数据显示不合理的请求使用连接严重的影响应用所能承受的并发数量，响应的时间也因此受到影响。
目前普遍存在的问题
没有把事务控制好，一般会出现以下的情况：
事务(){流程1();流程2();}
可以看出流程1，2里都是单独创建连接，并在自己的流程里完成操作。
假如在流程2里出现异常，那么流程1所做的操作是不可恢复的。
假如能控制在事务范围内，如：
事务(){Connection con;流程1(con);流程2(con);con.close();}
那么数据库少提供一个连接，事务的完成性也得到体现。在并发数量大的时候，效率上就有非常明显的区别。
解决方案
1. 尽量保持少的请求
如DAO中有update()方法，则应再扩展一个方法update(Connection conn)
在业务逻辑事务里调用update(Connection conn)，一般情况下调用update()
2.对于数据不变的情况采用缓存技术，或部分缓存技术。
可参照一些相关的开源的项目（JIVE）。
