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:

createModel.png

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

二、RepositoryServiceImpl.saveModel方法

我们进入repositoryService.saveModel方法:

saveModel.png

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

三、SaveModelCmd.execute方法

我们进入SaveModelCmd类:

SaveModelCmd.png

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

commandContext.getModelEntityManager().insertModel(model);

四、ModelEntityManager.insertModel方法

ModelEntityManagerinsertModel方法代码如下:

insertModel.png

五、DbSqlSession.insert方法

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

insert.png

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

六、DbIdGenerator.getNextId方法

getNextId.png

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

七、GetNextIdBlockCmd.execute方法

进入GetNextIdBlockCmd类:

GetNextIdBlockCmd.png

该execute方法中:
首先获取act_ge_property表中的next.dbid字段的值,传给oldValue;
idBlockSize:为2500,然后通过oldValuenewValue-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方法,数据变化结果如下:
页面效果:

image.png

数据库变化:

image.png
9.1、模拟测试环境新增模型

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

image.png

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

image.png

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

上一篇:Spring学习之整合Activiti(二)

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

你可能感兴趣的:(Spring学习之整合Activiti(三)之Id生成)