JBPM数据库因单条查询引发锁增长导致系统阻塞求助

我们在定制化企业CRM中使用JBPM管理流程，每周都会出现系统所有访问请求被阻塞的情况，阻塞源是以下SQL查询：

(@P0 nvarchar(4000),@P1 nvarchar(4000))select contextmap0_.mappingId as mappingI1_8_
, contextmap0_.CONTEXT_ID as CONTEXT_2_8_
, contextmap0_.KSESSION_ID as KSESSION3_8_.
, contextmap0_.OWNER_ID as OWNER_ID4_8_
, contextmap0_.OPTLOCK as OPTLOCK5_8_
from ContextMappingInfo contextmap0_
where contextmap0_.CONTEXT_ID=@P0 and contextmap0_.OWNER_ID=@P1

该查询会导致所有后续调用进入挂起状态，涉事ContextMappingInfo表仅约16000条记录（数据量不大）。

相关环境信息 #

• JBPM生产版本：7.56.0.Final
• OpenJDK版本：11.0.11 2021-04-20 LTS
  OpenJDK Runtime Environment 18.9 (build 11.0.11+9-LTS)
  OpenJDK 64-Bit Server VM 18.9 (build 11.0.11+9-LTS, mixed mode, sharing)
• 数据库连接驱动：Microsoft sqljdbc-8.2.2-ita

解决方案建议 #

1. 优化数据库索引 #

针对ContextMappingInfo表的查询条件CONTEXT_ID和OWNER_ID创建联合索引，避免全表扫描，减少查询执行时间和锁持有时间：

CREATE NONCLUSTERED INDEX IX_ContextMappingInfo_ContextOwner ON ContextMappingInfo (CONTEXT_ID, OWNER_ID) INCLUDE (mappingId, KSESSION_ID, OPTLOCK);

2. 排查JBPM上下文映射使用逻辑 #

• 检查是否存在大量并发请求同时查询相同的CONTEXT_ID和OWNER_ID组合，加剧锁竞争；
• 确认是否有未及时关闭Ksession的情况，导致相关记录被长时间锁定；
• 验证JBPM上下文清理机制是否正常，避免僵尸上下文记录积累影响查询效率。

3. 调整数据库锁策略与隔离级别 #

• 若使用SQL Server，可将事务隔离级别调整为READ COMMITTED SNAPSHOT ISOLATION，减少阻塞场景；
• 通过sys.dm_tran_locks视图查询数据库锁等待信息，定位是表锁还是行锁，针对性优化。

4. 升级JBPM版本修复已知问题 #

JBPM 7.56.0.Final可能存在上下文映射相关的性能或锁机制缺陷，可查阅官方发行说明，考虑升级到较新的稳定版本（如7.73.0.Final及以上）。

5. 优化资源配置 #

• 检查数据库连接池配置，确保连接数合理，避免连接耗尽导致请求排队；
• 调整JBPM线程池参数，控制并发流程实例数量，降低数据库锁竞争压力。

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