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

 

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....

 

(后来看了，SQLException有一些子类，但是这些子类，都是所，执行某个SQL时的错误，按照道理，都应该是数据库连接正常，但是SQL有问题，例如查询不存在的表等操作，而SQLConnectionException不应该是SQLException的子类)

 

那么这个问题会影响到什么呢？如果每次使用都是直接创建连接，使用并且关闭还好，遇到异常就关闭就完事了，但是我们知道，目前很多开发使用的都是连接池，池化连接的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早一天认识到这些基础库的问题，对这些东西进行一些梳理和改进，做好基础语言，别盲目的追逐热点，把高楼大厦建立在沙滩上。

 

 

 

 

 

 

 

 

评论

7 楼 windshome 2013-09-06  

我觉得一般分表、或者像大型数据库分区也行，总之存储层的性能存储层去解决，应用层只需要知道需要把数据存进去，还要再某个时间取出来就行。


跨库的事务，没有办法保证完整性，除非做很完整且啰嗦的完整性处理。跨表还好办。建议改成跨表方案，在一个连接、一个事务中保证完整性。

如果实在没有办法改结构，那么如果对数据一致性要求还那么高，那么就需要对每一个错误，做回滚。完成后，核对一致性，不一致的话，退回执行前的状态。这个太复杂了。

6 楼 Tyrion 2013-09-06  

windshome 写道

看到老兄你的意见很高兴，感觉JDBC不是粗糙而死缺乏好的设计和用心的设计，在设计时没有考虑使用者的真实情况。更别提设计JDBC 时，没有考虑将来会池化连接。

可气的不是这个，而是JDBC规范一版一版更新，这个早该提上日程的事情没有人考虑也没有人提。

在这个事情上，我倒是觉得通过上层去包装很绕，效果也很难好到哪里去，比如你提到Spring根据SQLState、ErrorCode做封装，这都像是房屋的地基不好，建筑到上边了，想办法来弥补，当然是一种方法，但是也很辛苦。

老兄对开源的推崇和我不同，我对开源的东西持慎重和保守态度，当然，很多开源的东西有非常高的价值，但是也有很多弊病，让人用起来爱恨难分。

说到连接池的实现和代码，我之前用的数据库连接池是自己写的，在非常苛刻的环境里运行了十年，从来没有因为连接池出过什么问题。为了设计和实现这个东西，参考和研究了一些实现。但是对开源框架，例如Spring、Hibernate等，却是不熟，我更熟悉的是底层JDBC、Socket连接、线程，所以老兄和我讨论这个可能会让我膛目结舌。不过也不妨碍说来听听，也许能给出点自己的看法，所谓愚者千虑或有一得嘛，说不定有高人看到给点启发性的意见呢。

呵呵，那就说下前段时间想了很久的涉及多数据源应用在框架层面保持事务一致性的问题。
场景是这样的：
1.我现在的项目中由于数据量等原因会涉及多数据库存储业务数据，典型的情况如千万级数据会分库分表来做。
2.有很多业务场景里一次请求中会涉及多个数据库的业务表记录的增删改，从业务逻辑上来说这些应该在同一事务中。
3.假设一次事务中要insert三个库中的业务表记录，我反编译了目前项目中的源码，实现方式是一个库对应会获取一个connection，业务方法开始是将这三个connection的自动提交事务属性置为false，完了在整个业务方法结束前将涉及到的三个connection逐个commit。

上述是我看到的源码，一开始我还以为是用XA来处理多数据源提交的业务场景，没想到我们项目里的框架代码是这么实现的，但对这种方式我有一点疑问，就是加入第一个connection已经commit成功，但第二个却失败了，这样将会产生错误数据。后来发现我们的框架在提交之前有个配置，可以校验一下connection的有效性，就是执行一下某个查询语句（如SELECT SYSDATE FROM DUAL），但这样也就是降低出错几率，总感觉实现方式还是粗糙。

不知你是否接触过这种场景，以及有没有什么更好的解决方案？

5 楼 windshome 2013-09-05  

看到老兄你的意见很高兴，感觉JDBC不是粗糙而死缺乏好的设计和用心的设计，在设计时没有考虑使用者的真实情况。更别提设计JDBC 时，没有考虑将来会池化连接。

可气的不是这个，而是JDBC规范一版一版更新，这个早该提上日程的事情没有人考虑也没有人提。

在这个事情上，我倒是觉得通过上层去包装很绕，效果也很难好到哪里去，比如你提到Spring根据SQLState、ErrorCode做封装，这都像是房屋的地基不好，建筑到上边了，想办法来弥补，当然是一种方法，但是也很辛苦。

老兄对开源的推崇和我不同，我对开源的东西持慎重和保守态度，当然，很多开源的东西有非常高的价值，但是也有很多弊病，让人用起来爱恨难分。

说到连接池的实现和代码，我之前用的数据库连接池是自己写的，在非常苛刻的环境里运行了十年，从来没有因为连接池出过什么问题。为了设计和实现这个东西，参考和研究了一些实现。但是对开源框架，例如Spring、Hibernate等，却是不熟，我更熟悉的是底层JDBC、Socket连接、线程，所以老兄和我讨论这个可能会让我膛目结舌。不过也不妨碍说来听听，也许能给出点自己的看法，所谓愚者千虑或有一得嘛，说不定有高人看到给点启发性的意见呢。

4 楼 Tyrion 2013-09-05  

JDBC对于SQLException的设计确实比较粗糙，所以当时看Spring对这块又重新根据各厂商的异常里的SQLState、ErrorCode做了一层封装，层次结构较清晰。能不能提升到API层面这个真心得靠运气，不过我对Java的规范层面的东西并不是很感冒，更多情况下是开源社区走在官方层面之前。

看来楼主研究过开源的连接池的代码，前段时间在看应用中涉及多数据源的事务在框架层面的解决方案时有些困惑，有空交流交流？

3 楼 windshome 2013-08-07  

但是没有连接错误的异常啊。别的是有分类。这个对后面连接池之类的设计是有很大影响的。

2 楼 sgq0085 2013-08-07  

贴主错了，BatchUpdateException, RowSetWarning, SerialException, SQLClientInfoException, SQLNonTransientException, SQLRecoverableException, SQLTransientException, SQLWarning, SyncFactoryException, SyncProviderException。这些都是继承至SQLException的。
就好比继承Exception的有很多种，但是为了方便直接cache Exception，这个跟设计无关吧，是程序员的事情

1 楼 maodou95838 2013-08-07  

拜读了。。。