我从没有深入了解过数据库连接池，我一直都把它当着理解幽灵引用（phantom reference）的一个示例。我参与的大部分项目里，数据库连接池都已经包含在我们选择的框架里。总而言之，对很多系统而言，数据库连接池是一个必要的组件，但是它被你用来和数据库交互的对象关系管理器（object-relational manager）所隐藏，对你而言是不可见的。
后来，我在Stack Overflow上回答了这个问题。为了回答这个问题，我特地把玩了一下数据库连接池，写了一个更长的答案。然后我意识到一个问题，数据库连接池，哪怕是最新的实现，都把目前最新的数据库管理的最佳实践给包含进去。其中两个特别重要的，就是：
- 数据库的凭证需要处理： 我所用过的所有连接池都需要你在配置文件里填写数据库凭证，也就是用户名和密码。这也就意味着，对一个有安全意识的开发人员，你需要从某个地方获取这个配置，然后加入到配置文件里。或者，对于一个没有安全意识的开发人员，直接将它们明文存储在一个文本文件里。不管是那个场景，你都是做一次配置，也就是在应用启动的时候。如果需要修改的话，你需要重启应用。这样的话，定期更新凭证就变得比较麻烦了，因为你需要定期更新凭证来避免因为它们被泄露而导致的问题。一种极端的场景就是，Amzon的RDS支持每15分钟更新一次凭证。但是，即使你的凭证是一个月更新一次，但是你还是需要重启所有的服务，这样的话，这个简单的操作就变成了一个大的应用变更，而且只能手动操作，并且会增加应用的宕机时间（downtime）。
- 故障恢复不重要：较早的时候，从主机切到备机来进行故障恢复是一个大事件，往往需要一个多人的电话会议，然后手动进行操作。即使是最简单的情况下，你也需要把一台备机切成主机，不过使用基于日志的异步同步策略，总还是会有数据丢失的可能性。而且，随着集群式的数据库（例如Amazon Aurora）的不断增加，故障恢复可能会在我们不知道的情况下自动进行。如果我们的应用没法感知到当前是处于故障恢复期间的一个时间段的话，那么就会有问题了。
一个针对以上两个问题的解决方案是给连接池添加一个钩子，用来调用用户自定义的代码，然后获取需要的信息。例如，对于从静态文件里读取用户名和密码的方式，可以替换成调用一个用户自定义的函数读取文件来获取。
然后就没问题了，但是这也让我想到了另外一个问题：实际上最根本的问题在于连接池在尝试解决两个不同的问题。第一个问题是管理连接池：创建连接，保持连接，销毁连接，如果应用没有主动关闭的话，还要对连接进行回收，并且要做到对性能的影响减到最少。第二个问题是建立连接，这个问题随着使用的数据库不同，会稍微有所变化。
我认为数据库连接池演进的下一个阶段就是把这些操作进行分离，然后连接池管理的代码会分解成一个可以自由搭配和组合的组件栈。对于有些人可能需要一个MySQL连接池的工厂（factory），然后需要使用IAM凭证提供者（provider），以及需要一个在每次获取连接之后，一旦发现连接是只读的，就抛出异常的检查策略（connection check）。另外一些人可能需要一个Postgresql的连接池工厂（factory），使用一个基于环境的凭证提供者（provider），而且只需要基本的连接检查（connection check）即可。
这里比较棘手的一个问题就是如何设计接口。我不认为我刚刚所提到的分成三部分的方式是正确的。但是我能肯定的是，仅仅重写javax.sql.DataSource肯定是不够的。除此之外，哪怕API已经设计好了，实现它也是需要很大的工作量的，但是我想还是能够找到很多人来参与贡献代码的。
那么最后的问题就是：有没有哪个数据库连接池的维护者跟我有相似的想法，并且愿意做这样的拆分呢？
