jBPM 6.5采用per_request运行时策略对接timer事件的注意事项问询

核心注意事项 #

• Timer事件持久化与上下文绑定：per_request模式下每次请求生成的RuntimeEngine实例仅在当前请求生命周期内存活，timer事件本身持久化存储在jBPM的ProcessInstanceInfo、TimerInstanceInfo数据库表中，和RuntimeEngine实例无关。但timer触发时会自动初始化对应流程实例的RuntimeEngine上下文，必须保证触发请求的类加载器、流程定义资源和部署时完全一致，禁止出现流程定义热更新后未同步到所有集群节点的情况。
• 事务边界适配：per_request默认事务和当前请求绑定，而timer触发属于jBPM异步调度请求，事务的超时时间、回滚策略必须和常规业务请求做区分，不能直接复用普通接口的事务配置，否则容易出现timer触发时事务超时回滚，导致timer反复无效重试。
• 并发调度去重配置：per_request模式没有singleton策略的全局锁机制，集群部署时多个节点同时扫描到同一个待触发timer会出现重复触发问题，必须开启jBPM的timer乐观锁机制，依赖数据库表的版本号字段避免重复执行业务逻辑。
• 会话资源显式释放：每次timer触发完成后，必须显式调用RuntimeEngine的close方法释放会话资源，per_request模式默认只会在前端发起的请求结束时自动释放资源，异步timer触发的请求如果没有显式释放逻辑，会导致KieSession泄漏，内存持续上涨。

生产落地重点排查风险点 #

• 集群timer调度冲突：验证多节点部署场景下，同一个周期timer/一次性timer会不会被多个节点同时触发，检查TimerInstanceInfo表的VERSION字段是否每次触发后正常递增，出现乐观锁异常时是否会自动重试且不会重复执行业务逻辑。
• 长周期timer上下文一致性：测试间隔超过7天的长周期timer触发时，若流程定义有小版本迭代、自定义业务类有更新，会不会出现类找不到、流程实例变量反序列化失败的问题，必须保证流程定义的部署ID和流程实例绑定，不能覆盖旧版本的部署资源，自定义业务类修改时要保证serialVersionUID一致。
• 异常场景重试逻辑合理性：模拟timer触发时业务抛出非RuntimeException、数据库断连等异常，查看timer会不会被误标记为失效，是否会按预期配置的间隔重试，不会出现短时间内反复重试打爆数据库的情况。
• 资源占用风险：压测1000+并发流程实例同时存在待触发timer的场景，观察JVM内存是否持续上涨，是否存在KieSession未释放的泄漏问题，Tomcat/SpringBoot的异步线程池是否有被timer调度任务占满的情况。
• 时序类执行风险：模拟多个timer触发时间间隔小于100ms的场景，检查业务逻辑的执行顺序是否和BPMN定义的一致，有没有出现后触发的timer先执行完导致业务逻辑错乱的问题，必要时在业务层加分布式锁保证执行顺序。

内容的提问来源于stack exchange，提问作者Scott J.