Spring学习之整合Activiti（三）之Id生成

上一篇：Spring学习之整合Activiti（二）

下一篇：工作流Activiti异常积累

在Spring学习之整合Activiti（一）的测试环节进入modeler.html创建模型页面时需要传modelId，那么这些Id是如何生成的（Activiti中的所有的id：act_ge_bytearray、act_re_deployment等等中的主键生成基本一致）？
在本章节，我们跟着源码查看一下：

一、ModelService.createModel方法

进新建模型页面首先调用ModelService（示例中的类）中的createModel（）方法获取modelId：

如上在两处打印modelData.getId()，很容易得知，modelId是在repositoryService.saveModel(modelData)中生成的

 

二、RepositoryServiceImpl.saveModel方法

我们进入repositoryService.saveModel方法：

该方法实际调用的是SaveModelCmd类中的execute方法

三、SaveModelCmd.execute方法

我们进入SaveModelCmd类：

SaveModelCmd.png

新建模型时，model.getId()是为null的，所以这里调用的是：

commandContext.getModelEntityManager().insertModel(model);

四、ModelEntityManager.insertModel方法

五、DbSqlSession.insert方法

继续进入DbSqlSession.insert方法查看：

dbSqlSessionFactory.getIdGenerator().getNextId()调用的是DbIdGenerator中的getNextId方法

六、DbIdGenerator.getNextId方法

getNextId.png

可以看到，modelId生成逻辑主要在该类中，
在getNextId方法中，判断lastId是否小于nextId，而这个条件中的lastId和nextId只是一个成员变量，在DbIdGenerator实例销毁后，lastId和nextId就会被重置，说明重启服务后lastId和nextId就会被重置，
会执行getNewBlock方法重新生成lastId和nextId，最后返回nextId；
在getNewBlock方法，我们看看第一句IdBlock是怎么生成的，调用GetNextIdBlockCmd类的execute方法

七、GetNextIdBlockCmd.execute方法

进入GetNextIdBlockCmd类：

该execute方法中：
首先获取act_ge_property表中的next.dbid字段的值,传给oldValue;
idBlockSize:为2500,然后通过oldValue和newValue-1生成IdBlock

八、IdBlock类

IdBlock.png

九、遇到的坑

以上生成id的逻辑，在不手动操作数据库是没有问题，比如，所有的流程模型都是在网页上新建的，但是如果某些模型数据是直接操作数据库，插入时会报主键重复：

场景：
在测试环境的网页上新建模型，并导出该模型的数据记录，然后导入到生产环境的数据库中，这里可能出现的情况是：
生产服务启动服务后会部署流程模型，而此时部署id是act_ge_property表中的next.dbid字段的值；而部署后也会往act_ge_bytearray表插入数据，从上面的源码可以看出：act_ge_bytearray表中的id是act_ge_property表中的next.dbid字段的值nextId+1
而由于测试环境的modelid也有可能是act_ge_property表中的next.dbid字段的值（启动服务后直接新建模型），新建模型时会将模型的xml文件插入到act_ge_bytearray表，此时act_ge_bytearray表中的该模型的id是act_ge_property表中的next.dbid字段的值nextId+1，如此便与生产服务的部署id冲突！

针对上述问题，我们模拟一下：准备一张表：init_activities_20190321.sql （生产上的sql）

9.1、模拟生产环境

首先我们模拟生产环境：
我们往数据库中导入init_activities_20190321.sql
随便部署一个模型，调用deploy方法，数据变化结果如下：
页面效果：

数据库变化：

9.1、模拟测试环境新增模型

然后模拟测试环境：往数据库中导入init_activities_20190321.sql三张表的结果如下：

然后启动服务，新增两条模型，数据库变化如下：

 

可以看到，测试环境的act_ge_bytearray中新增的模型中有两条数据的id与生产环境的act_ge_bytearray中的两个数据的id一致，这样的，如果将测试环境该三个表中的新增的模型数据导出来，命名为update_activities_20190517.sql；在生产环境运行，就会报主键冲突。
解决方案可查看工作流Activiti异常积累 异常4部分