工作流的学习（四）

这章我主要记录一下自己遇到的问题和总结。

（1）activiti的配置中，对于history的配置是可以优化的。

历史信息级别可以配置成以下几种:

none

: 忽略所有历史存档。这是流程执行时性能最好的状态，但没有任何历史信息可用。

activity

: 保存所有流程实例信息和活动实例信息。 在流程实例结束时, 最后一个流程实例中的最新的变量值将赋值给历史变量。 不会保存过程中的详细信息。

audit

: 这个是默认值. 它保存所有流程实例信息, 活动信息, 保证所有的变量和提交的表单属性保持同步 这样所有用户交互信息都是可追溯的，可以用来审计。

full

: 这个是最高级别的历史信息存档，同样也是最慢的。 这个级别存储发生在审核以及所有其它细节的信息, 主要是更新流程变量。

(2)执行的任务的参数设置，尽可能的少设置几个属性，这对性能也有影响

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。

这块要特别注意。虽然查询其他各种表用这种方式都可以执行。