这章我主要记录一下自己遇到的问题和总结。
(1)activiti的配置中,对于history的配置是可以优化的。
历史信息级别可以配置成以下几种:
-
none
: 忽略所有历史存档。这是流程执行时性能最好的状态,但没有任何历史信息可用。 -
activity
: 保存所有流程实例信息和活动实例信息。 在流程实例结束时, 最后一个流程实例中的最新的变量值将赋值给历史变量。 不会保存过程中的详细信息。 -
audit
: 这个是默认值. 它保存所有流程实例信息, 活动信息, 保证所有的变量和提交的表单属性保持同步 这样所有用户交互信息都是可追溯的,可以用来审计。 -
full
: 这个是最高级别的历史信息存档,同样也是最慢的。 这个级别存储发生在审核以及所有其它细节的信息, 主要是更新流程变量。
Task task = taskService.createTaskQuery().taskId(taskId).singleResult();
Map<String, Object> variables = new HashMap<String, Object>();
// 任务审批Key
String taskApproveKey = getTaskApproveKey(task);
// 审批不通过
variables.put(taskApproveKey, Constants.IS_FALSE);
taskService.setVariablesLocal(taskId, variables);
这里可以使用json的形式,将多个参数设置一个varible里面。通过测试,这里varible设置的越多,执行越慢。
(3)死锁问题
我出现的问题,是两个系统访问同一个activiti数据库,导致死锁。死锁的相关问题在我数据库死锁的文章中有。
解决的办法:1)可以写一个通用的activti服务,比如activiti相关的添加,删除,修改,查找等,多个系统访问这个服务,在服务上对锁加以控制。
2)对出现死锁的字段检查,没有索引的加索引,因为对于索引的查找是行锁,不是表锁。
3)重写Activiti的操作,不适用activiti jar包中的方法,(ibatis对于activti jar包中的select的使用默认没有加with(nolock),所以我们自己写方法,加上with(nolock),不过这种方法很麻烦,比较jar包封装了很多方法,添加一条任务的整个流程涉及到的表我们都要处理,这就要求很了解整个任务处理的过程)
(4)activiti性能问题
我的项目里主要是因为涉及到了两个数据库。将activiti的act_id_表都设计成了视图。这里主要是业务需要。而视图查找的是另一个数据库的表,所以在我们的项目中,工作流添加这块很慢。
后来我将这块做了修改,即将视图去掉,改为表,然后在项目中添加监听器,对涉及到这个表的修改的事件都添加监听,只要有事件发生,我就修改相关表,当然这也没提高多少,最多提高40%的性能。
(5)
List<User> users = identityService
<span style="white-space:pre"> </span>.createNativeUserQuery()
<span style="white-space:pre"> </span>.sql("SELECT distinct [GROUP_ID_] as [ID_] FROM [Activiti].[dbo].[ACT_ID_MEMBERSHIP] with(nolock) WHERE GROUP_ID_ LIKE '"
<span style="white-space:pre"> </span>+ orgId + "_%'").list();
调用identityservice执行自己写的脚本,遇到问题:createNativeUserQuery的时候如果后面,select出多个字段,只有他的主键id_会有值,其他的属性即使as到user对应的属性,也不会有值。
我当时是想用membership里面的其他属性,可是就说一直查不到,因为直接执行脚本是有的,最后才发现直接这样除了主键有值,其他均为Null。
这块要特别注意。虽然查询其他各种表用这种方式都可以执行。