在任何类型的请求 – 回复系统中 – 无论是http,ftp还是数据库调用 – 保持一个连接池可供客户端使用是有意义的.在每个请求期间构建和拆除连接的成本很高(对于客户端和服务器而言都是如此),因此拥有一个池,多个线程可以从中“检出”连接以供其使用,这是一个很好的模式.

履行

JDBC API提供了围绕任意数量的数据库实现的包装器,这意味着调用者可以(大部分)不知道他们正在调用什么类型的数据库.这种抽象允许编码人员创建通用库,为任何类型的JDBC连接提供连接池.

这是连接池的Sun page和MysqL的here’s one.

由于调用者可能只使用JDBC方法,因此结帐可能看起来像创建连接的请求,而checkin只是关闭连接的调用者,即调用者不知道他们正在使用连接池,因为语义无法区分使用单一连接创建/拆除解决方案.这是件好事;这是真正的OO.

图书馆

那么有哪些库可以使这更容易？

> c3p0 – 以每个人最喜欢的协议droid命名,这个库提供连接池和预处理语句池(我相信这是PreparedStatement对象的对象池).

他们网站上的文档非常详尽.我实际上已经在我的桌子上打印了一份物理副本,因为我在调整时需要查阅它.所有配置都以JavaBeans样式完成,这使得使用它变得轻而易举.

它被广泛部署并在压力下站起来.我已经用它来做几十甚至几十万个每秒事务,多台机器和每台机器多个线程连接到多个数据库.

他们似乎有一个特别关于配置c3p0供Tomcat使用的appendix,所以你可能希望检查一下.
> DBCP – 名称较少的Apache DBCP(用于“数据库连接池”)与c3p0完全相同.这个discussion似乎不鼓励使用它,认为c3p0更积极地维护.我真的不记得为什么我选择c3p0而不是DBCP用于我的上一个项目(可能熟悉),但是如果你想让DBCP看一下,那就继续吧.

以下是有关DBCP的一些Stack Overflow问题：

> Connection pooling options with JDBC: DBCP vs C3P0
> Is DBCP (Apache Commons Database Connection Pooling) still relevant?

我不想成为负面的南希,但我不认为DBCP是你想要的.
> BoneCP – 也许创造性地命名,但听起来有点奇怪.我从来没用过它.作者说这是really fast,他可能是对的.这似乎是最不成熟的 – 至少在时间上 – 你的所有选择,但你应该试一试,看看它是否符合你的需要.

缺点

您将DataSource包装在类似其他类的代理中,因此可能无法访问特定于供应商的方法.这不是什么大问题：你不应该编写特定于供应商的数据库代码.