从设计不足的JDBC，说到数据库链接池

2013-08-12

JDBC是Java里边一个很重要的组成部分，现代的很多软件应用，都和数据库相关，因此，JDBC起着日益重要的作用。即便一个Java开发工程师不怎么直接使用JDBC，而是使用ORM等框架，但是这些框架也是给予JDBC包装而来的。因此，JDBC的不足，也给这些ORM还有数据库连接池组件带来了很大的不便。

我们知道，Java的Statement（和PreparedStatement），在execute查询和执行语句时，都需要检查 SQLException，这个SQLException实际上表示的涵义太宽泛了，这也就是我在题目中提到的“缺乏设计”，实际上，一个 Statement，执行的时候出错，有着多种可能，应该把这些错误分一下类来设计，这样表示的更清楚。

比如。在Statement去执行一个SQL时，很有可能是其所依赖的Connection被关闭了，这个时候，执行语句跑出的SQLException实际上是不合适的，应该是SQLConnectionException；

比如，要去一个不存在的表中select，执行时，跑出SQLException实际上是很对的；

但是我们看到，不管JDBC的版本怎么提升，从来也没有出现过SQLConnectionException这种东西，不管SQL执行时除了什么错，都是SQLExceptin。这非常像当初刚刚学Java时，写一个接口，通通声明为抛出Exception....

那么这个问题会影响到什么呢？如果每次使用都是直接创建连接，使用并且关闭还好，遇到异常就关闭就完事了，但是我们知道，目前很多开发使用的都是连接池，池化连接的close不是真正的关闭，而是将连接送回池中。

例如代码为：

Connection conn = null;

try{

conn = pool.getConnection();

conn.....

}catch(Exception ex){

...

}finally{

if(conn!=null)conn.close();

}

题在于，如果出现异常了（一般是SQLException），应该怎么处理？按照逻辑，应该是如果是SQL查了一个不存在的表之类的，当然是连接回池，如果是连接坏了，当然是直接关闭。

但是现在我们能判断吗？因为只有SQLException，我们判断不出来。

根据SQLException的Message判断吗？不同数据库，Message是不同的。。。

还有可恨的，大多数数据库连接池，实际上是不向外提供“真正关闭一个连接”这个操作时，当然，这么做的考虑是为了屏蔽池化连接和直接创建的连接的区别，但是，这个接口封上之后，面对的这种问题应该怎么处理呢？

目前。大多数连接池也有一种办法解决，就是配置一个SQL，每次取出一个连接用的时候，都先执行一下，如果出错，表示连接坏了，连接池（连接池自身当然能够真正关闭连接）真正关闭这个连接，给一个新的连接供外部请求者使用。但这是个拙劣的方法，因为一个SQL意味着和数据库的一个TCP交互，性能的损耗是客观存在的，高并发、高效率的系统不应该用这种方法。

如果JDBC能够区分，那么将省去了很多麻烦，不管在连接池内部处理还是外部处理，至少都是符合逻辑的。在这里也建议使用一些开源数据库连接池组件的朋友们，如果你要选择一种连接池，一定注意这种连接池这种情况下的处理，是怎样设计实现的，这一是表明了开发者考虑问题是否周全，而是关乎系统效率和稳定性。

可能有的朋友会问，Java不会这么缺乏好的设计吗？我其实也不希望Java有这种缺陷，希望有一种好的机制来解决我的问题，但是很可惜没有看到。之前曾经花了很大的力气研究Java的源码，曾经认为Java有很多地方值得学习，所以去研读。结果发现，有很多代码非常好，同时也发现很多代码很糟糕；甚至不是实现代码的问题，而是设计时粗枝大叶。

一时、一天细心容易做到，但是在职业生涯中总保持细心、周全的考虑问题并不是件容易的事情，所以虽然觉得这里有问题，但是也不是嘲讽或者责难别人，而是希望Java早一天认识到这些基础库的问题，对这些东西进行一些梳理和改进，做好基础语言，别盲目的追逐热点，把高楼大厦建立在沙滩上。