[翻译]Why another connection pool project？为什么还需要另外的连接池项目？

英文原文： http://www.tomcatexpert.com/blog/2010/03/12/explaining-jdbc-pool-high-concurrency-alternative-connection-pooling-module

原文发表于2010年3月12日

 

      这篇文章我们将解释Tomcat开发版本中的一个组件。这个组件的名字就是jdbc-pool，准确地说，他是JDBC 资源池的一种实现。

      连接池已经存在很久了。1997年我刚刚接触java的时候就自己写了一个连接池，并且应用到了我参与的不同项目中。当JDBC出现以后，开发者很快意识到，连接池会对性能非常有益，并且是一条复用连接、管理管理数据库连接资源的途径。在数据库负载严重的水平扩展情况下这种方法非常重要。那时我们用来运行应用服务器的典型机器是1、2某些时候是4核CPU。

      连接池技术很快被某些J2EE厂家集成到自己开发的事务服务中，甚至成为私有的并集成到服务上。除J2EE以外，大量的开源项目开始流行。例如Proxool,Apache Commons DBCP,C3P0和Poolman。这些是我们在这个领域中见到最多的。Apache Tomcat 多年以来一直以来DBCP为其用户提供连接池实现。

      所有的开源项目都有优点和缺点，但也都有普通的一面。他们变得落伍，并且在这些基本的代码没能继续适应新的java语言特性，甚至没有对正在普及的多核java应用开发平台进行优化。还有一些项目因为不必要的复杂的代码结构饱受批评，主要原因是这些项目的代码没有与时俱进，变得晦涩难懂、难以维护。

      在我们上面提到的开源项目中，可以看到现在跟Apache Tomcat同时部署的有Commons DBCP和C3P0。这里简短描述一下这两个项目：

      Commons DBCP

• 与Tomcat一同发布，可以直接使用
• 非常稳定的代码基础
• 很长时间内存在存在令人厌恶的死锁问题
• 拥有低频率、多并行的用户往往抱怨其吞吐量瓶颈

      C3P0

• 经常用来被替代DBCP
• 基于我们在这个领域的经验，其仍然有很多bug
• 声望要好于DBCP，虽然我们的测试结果不同

     这两种实现都非常复杂。DBCP建立在Apache Commons Pool项目上，并且一共有60多个源文件。C3P0增长到200多源文件。而且两种连接池都输在缺少特性上，例如：

• 连接池一般严格绑定在一个Java版本上。意味着如果这个连接池为java5所写，那么他不会兼容java6的java.sql和javax.sql接口
• 连接池被限制在java.sql.Driver接口，所以不能提供继承javax.sql.DataSource的资源
• 不支持XA数据资源
• 没有可插拔的扩展特性

回到我们的问题，为什么需要另外一个连接池项目？答案很简单，我们需要更好的性能和更多的特性。我们也相信让一个传统项目达到这样的要求需要重新大量的基础代码。所以，我们果断的质疑，我们确实需要重写60多个源文件，甚至是200+吗？

      我知道你也许在想，还有其他工程师相信，重写那些让人抓狂的代码比捐献这些现存的代码更好。大多数情况下，我更喜欢重用和修复，而不是重写。即便如此，请先考虑如下问题：

• 实现一个完全相同功能的DBCP，我们到底需要多少行代码？
• 我们能否提供灵活的实现，提供所有的驱动程序实现的java.sql.Connection接口？（**杜天微注：例如连接池在JDK 1.5环境下编写，不能提供JDK1.6中新增加的方法实现。如果应用程序在java6环境开发，并且驱动程序支持java6的JDBC接口，如果连接池只支持java5接口，那么新的接口仍不能被使用。）
• 我们能否提供一个框架来暴露附加的特性？
• 我们能否让实现在多核环境下提高性能？

      我们将要面对的下一个挑战是这样一个项目，在Apache软件基金会里，怎样建立一个围绕项目的社区。社区往往伴随着大量未完成的代码成长，这意味着，为了让一组人员一起工作，还有很多工作不同领域的工作要做。

      现在，我们有了一个标准，8个源文件，请且提供所有其他连接池特性。并不是令所有java开发者都兴奋。从社区的观点看，启动一个独立的项目也许并不那么有效。我们因此把它增加到24个源文件，基本上都是建立一些预置的可配置的附加组件。

      所以jdbc-pool组件启动。

      jdbc-pool借鉴了之前的实现，并且bug数量很低。很多早期的bug是明显的围绕java.sql接口的，例如多次调用一个连接的close方法等。

      今天我们再看jdbc-pool，甚至是未释放状态，仍有一些产品在使用。SpringSource ships the pool module with its tc Server product ，并且你已经可以从博客中看到一些关于它的信息。

      jdbc-pool拥有与DBCP几乎完全相同的配置（**杜天微注：这个页面正式发布在Tomcat7的文档页中），以便提供一个简单的迁移补丁。对于已经使用Tomcat和DBCP的用户，唯一的不同只是工厂属性  factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"。

      对于依赖注入框架的用户，例如Spring Framework，只要很简单的配置 org.apache.tomcat.jdbc.pool.DataSource的bean。

      平民化，这就是为什么我们需要另外一个JDBC连接池组件。在后面的几篇文章中，我将深入挖掘：

• jdbc-pool的性能
• 何时、怎样使用特性集合
• 实现和为什么会有提升
• 怎样建立扩展

 

 

作者简介：

Filip Hanik是来自VMware公司的SpringSource部分的高级软件工程师、Tomcat的积极倡导和参与者。**杜天微注：后面不翻译了，有兴趣的同学自己看看