数据库连接池泄露后的思考

滥用的后果

及时将配置调整成了200，服务重启也恢复了正常，但是我仍然认为系统存在连接泄露的风险，我试图从日志表现出的行为里寻找蛛丝马迹。我在访问日志看到每次在系统崩溃前，其实都有人在做构建，而且构建经常点击没反应，我当时添加的构建debug日志也显示了这一点。我开始怀疑是构建造成的连接泄露。

在这里我简单说下构建代码处的逻辑

• 用户触发构建
• 将job加入增量job缓存，用于更新job状态
• jenkinsClient调用jenkins的api，开始构建
• 将构建信息写入数据库(jobname，version)

我开始观察自己写的代码，可是看了多遍，我也发现不了这段代码和数据库连接有啥关系，大多数人包括当时自己来说，数据库连接的泄露，大多数情况应该是服务和数据库连
 

是当时的代码入口，当然代码处没有这么简单。可以看到我在方法入口就加上了Transactional注解，这里的意思其实就是发生错误，抛出异常时，数据库回滚。

问题就出现在了这里，当有用户点击构建时，请求刚进入build方法时，就会从数据库连接获取一个连接。可是此时，程序并没有和数据库相关的操作，如果此时代码在步骤1或者2处出现io或者网络阻塞，就会导致，事务无法提交，连接也就会一直被该请求占用。而再大的连接池也会被耗费殆尽。从而造成系统崩溃。

2.2事务注解的正确用法

通常情况下作为非业务部门，没有涉及到核心的业务，像支付，订单，库存相关的操作时，事务在可读层面并没有特别高的要求。通常也只涉及到，多表操作同时更新时，保证数据一致性，要么同时成功要么同时失败。而使用

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!