Druid连接池源码解析(7)ExceptionSorter&ValidConnectionChecker

1 ExceptionSorter&ValidConnectionChecker

ExceptionSorter&ValidConnectionChecker 都是com.alibaba.druid.pool.vendor包下面的组件,
这篇应该是pool包的最后一篇了,看一下mysql下典型实现的类图:


ExceptionSorter.png

ValidConnectionChecker.png

关系都比较简单,都是对应各种不通数据库的实现。

2 ValidConnectionChecker

ValidConnectionChecker是在dataSource中的init()->initValidConnectionChecker()方法中初始化,根据DriverClass生成相应数据库的checker,调用的话在validateConnection和testConnectionInternal两个方法中

  • validateConnection 在createPhysicalConnection和shrink中调用(shrink是缩小连接池时,发现连接不可用直接废弃)
  • testConnectionInternal在遇到testWhileIdle,testOnBorrow,testOnReturn时会调用,验证连接的有效性;
    如果有相关数据库的ValidConnectionChecker,则使用ValidConnectionChecker验证
    如果没有ValidConnectionChecker,则直接使用validationQuery验证;MySqlValidConnectionChecker会使用Mysql独有的ping方式进行验证,其他数据库其实也都是使用validationQuery进行验证

3 ExceptionSorter

官方对于这些ExceptionSorter的作用是这么定义的:

当网络断开或者数据库服务器Crash时,连接池里面会存在“不可用连接”,连接池需要一种机制剔除这些“不可用连接”。在Druid和JBoss连接池中,剔除“不可用连接”的机制称为ExceptionSorter,实现的原理是根据异常类型/Code/Reason/Message来识别“不可用连接”。没有类似ExceptionSorter的连接池,在数据库重启或者网络中断之后,不能恢复工作,所以ExceptionSorter是连接池是否稳定的重要标志。

具体调用是在Connection异常发生时,最后都会落到DruidDataSource的handleConnectionException方法,主要就是判断是否Fatal error,不是就继续往外抛异常,是的话,就调用handleFatalError,最终把连接物理关闭

4 总结

本篇主要是driud对于异常的判断和处理的流程总结,是init()中的一些细节的补充;
由于远程IO连接的特性,不能在连接一有异常的时候,系统就能感知到,所以用了上述方式去处理,在业务中也是值得借鉴的,即:

  • 对于异常的诊断与处理解耦
  • 异常的处理可以按异常等级的划分,同过异常传递机制,分别处理
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容