650) this.width=650;" src="http://s3.51cto测试数据/wyfs02/M01/6C/D1/wKioL1VTJsTD8tqCAAFeCrguy0E961.jpg" style="float:none;" title="2 (1).PNG" alt="wKioL1VTJsTD8tqCAAFeCrguy0E961.jpg" />
650) this.width=650;" src="http://s3.51cto测试数据/wyfs02/M01/6C/D6/wKiom1VTJUrxHZcuAAC-xmfymC4240.jpg" style="float:none;" title="请假步骤.PNG" alt="wKiom1VTJUrxHZcuAAC-xmfymC4240.jpg" />
找到我起草这一块的 sql ，如下：
LEFT JOIN T_BPM_PROCESS_TASK task ON task.processExecutionId = Execution.id AND task.taskId= ( select max(taskId) from T_BPM_PROCESS_TASK task2 where task2.processExecutionId = Execution.id)
左连接 task 的 activityName 即为当前步骤。以上逻辑是基于 taskId 是按照某种规则向上增长的，先处理的环节的 taskId 肯定比后处理的 taskId 小，但通过这个例子，也已经发现 taskId 并不严格按照向上增长的规律变化。
找到创建新任务的入口（ TaskServiceImpl ）
commandService.execute(new NewTaskCmd(parentTaskId))
这是一个命令模式，进入 NewTaskCmd ，进入 execute() 方法，再进入 DBSessionImpl 的 createNewTask() 方法，然后是 createTask() ，在这个方法里有的生成方法
long dbid = EnvironmentImpl.getFromCurrent(DbidGenerator.class).getNextId();
上面是反射的应用，进到 DbidGenerator 的方法 getNextId() ，这是一个被同步的方法，每次只能有一个调用进入。我们再依次进入核心的方法 acquireDbidBlock() ，然后又是一个命令模式， AcquireDbidBlockCmd 的 execute ，下面我们可以看到
PropertyImpl property = (PropertyImpl) session.createCriteria(PropertyImpl.class)
.add(Restrictions.eq("key", PropertyImpl.NEXT_DBID_KEY))
.uniqueResult();我们打开 jbpm_property ，里面有一条数据，指定的是 id 的生成方法以及步长。
650) this.width=650;" src="https://img./e/u261/themes/default/images/spacer.gif" border="0" style="background:url("/e/u261/lang/zh-cn/images/localimage.png") no-repeat center;border:1px solid #ddd;" alt="spacer.gif" /> 650) this.width=650;" src="http://s3.51cto测试数据/wyfs02/M02/6C/D6/wKiom1VTJYDhnhxJAAAxwhQxAR0849.jpg" title="Catch.jpg" alt="wKiom1VTJYDhnhxJAAAxwhQxAR0849.jpg" />
打开 jbpm.task.hbm.xm l 可以看到
<id name="dbid" column="DBID_"> <generator class="assigned" /> </id>
通 过 ibernate 的 generator 属性的意义 这篇文章，我们可以知道 assigned 的用法，即
assigned （程序设置）
让应用程序在 save() 之前为对象分配一个标示符， 在 save前通过自定义的 id 生成器生成了 id。
大家都知道 activiti5 和 jbpm5 的区别和联系 ，
Activiti5 出自 Tom 之手，在 DBID 生成器的实现这块是一样的，下面是一篇对 activiti5 的 ID 自定义生成器的解释：
2 、 activiti5 的默认主键策略分析：
（ 1 ）每次需要主键的时候从 act_ge_property 表中的 next.dbid 中获取下一个主键值，但是主键增长步长是 100 ，也就是说每次从这里获取下一个值的时候，上次是 100 ，下次的值是 200.
（ 2 ）他们所有需要主键的表都从这个表中获取下一个值
（ 3 ）但是他们针对性能做了一个取巧处理，就是每次步长 100 ，将这个步长 cache 在本地用 sychronize 方法调用，也就是说一段时间内只需要在本地获取主键即可，不需要访问数据实时更新，一定程度的缓解了数据库调用压力
（ 4 ）但是对于高并发来说，这个只能局部缓解，并发写入压力，还是有造成主键重复的概率
通过以上的解释，不难发现为什么 jbpm4 的 DBID 会出现小的情况，这与主键重复的原理是相似的。
通过以上分析，我们将我起草的查询逻辑改为：
AND task.createTime = ( select max(createTime) from T_BPM_PROCESS_TASK task2 where task2.processExecutionId = Execution.id limit 1)
本文出自 “南湖矿工技术空间” 博客，请务必保留此出处http://jncumter.blog.51cto测试数据/812546/1651047
JBPM的DBID自增长的实现
标签：jbpm