Camunda连接RDS/MySQL时连接关闭引发ProcessEngineException问题

我之前在维护Camunda + AWS RDS MySQL的集群时，碰到过几乎一模一样的问题——连接池明明保持着活跃连接，但偶尔会突然抛出ProcessEngineException提示连接已关闭。结合你的描述和日志信息，分享几个我亲测有效的排查和解决方向：

1. 处理RDS的空闲连接回收机制 #

AWS RDS MySQL默认会自动关闭空闲超过8小时的连接，但如果你的连接池没有配置连接有效性检测，连接池里的连接被RDS踢掉后，Camunda依然会认为这是可用连接，拿来使用就会触发异常。

解决配置（以常用的HikariCP连接池为例） #

在你的数据源配置中添加以下参数，让连接池定期检测并替换失效连接：

# 从连接池获取连接时检测有效性
spring.datasource.hikari.test-on-borrow=true
# MySQL的有效性检测语句
spring.datasource.hikari.validation-query=SELECT 1
# 检测超时时间
spring.datasource.hikari.validation-timeout=5000
# 每隔5分钟运行一次连接清理
spring.datasource.hikari.time-between-eviction-runs-millis=300000
# 设置连接最大生命周期（要短于RDS的空闲超时，比如设为30分钟）
spring.datasource.hikari.max-lifetime=1750000

如果使用的是Tomcat JDBC连接池，配置类似：

spring.datasource.tomcat.test-on-borrow=true
spring.datasource.tomcat.validation-query=SELECT 1
spring.datasource.tomcat.time-between-eviction-runs-millis=300000
spring.datasource.tomcat.min-evictable-idle-time-millis=1800000

2. 校验Camunda的事务与连接释放逻辑 #

有时候异常是因为连接没有被正确释放回连接池导致的：

• 检查你自定义的Java Delegate、Listener或者REST接口中，是否有手动操作数据库连接但未正确关闭/提交事务的情况；
• 确认Camunda的事务超时设置（transaction-timeout）是否与RDS的连接超时匹配，避免因事务超时导致连接被强制关闭。

3. 优化连接池的基础配置 #

你提到连接池始终保持5个活跃连接，建议检查以下配置：

• minIdle：确保最小空闲连接数设置合理，避免连接池无法及时补充被RDS回收的连接；
• maxWait：设置合理的连接等待超时时间，防止线程因等待失效连接而阻塞；
• maxPoolSize：如果业务高峰时连接需求超过当前池大小，也可能导致连接复用出现问题，可根据实际负载调整。

4. 开启详细日志定位问题 #

如果以上方法还没解决，建议调高日志级别来追踪连接的生命周期：

• 将Camunda持久层日志级别设为DEBUG：org.camunda.bpm.engine.persistence=DEBUG；
• 将连接池日志级别设为DEBUG（比如HikariCP：com.zaxxer.hikari=DEBUG）；
  这样可以清晰看到连接的获取、使用、释放过程，精准定位是哪个环节出现了失效连接。

内容的提问来源于stack exchange，提问作者Destructor