TaskQuery slow with many tasks

[pcsquirrel]

Hi,

first off all CONGRATULATION - ACTIVITI is really a awesome framework.

I´m just implementing an application using Activiti and fiddling for better performance. While doing that I discoverd that Taskquery is rather slow if I have many Tasks. Let me explain:

I have 100 Tasks for group "management".
I want to list them all and do a TaskQuery:

List<Task> tasks = tasksvc.createTaskQuery().taskCandidateGroup("management").list();
‍‍‍

This query issues 1+N SELECT-Statements against the database which is quite slow.

1.

select distinct T.* from ACT_RU_TASK T inner join ACT_RU_IDENTITYLINK I on I.TASK_ID_ = T.ID_ WHERE T.ASSIGNEE_ is null and I.TYPE_ = 'candidate' and ( I.GROUP_ID_ IN ( ? ) ) 
Parameters: management(String)
‍‍‍‍

N times for each Task returned by previos Query

select * from ACT_HI_TASKINST where ID_ = ? 
Parameters: 2390(String)
‍‍‍‍

As far as I have seen this is caused by the function "setTaskDefinitionKey" in class TaskEntitiy

  public void setTaskDefinitionKey(String taskDefinitionKey) {
    this.taskDefinitionKey = taskDefinitionKey;
    
    CommandContext commandContext = Context.getCommandContext();
    if(commandContext != null) {
      int historyLevel = Context.getProcessEngineConfiguration().getHistoryLevel();
      if (historyLevel >= ProcessEngineConfigurationImpl.HISTORYLEVEL_AUDIT) {
        HistoricTaskInstanceEntity historicTaskInstance = commandContext.getDbSqlSession().selectById(HistoricTaskInstanceEntity.class, id);
        if (historicTaskInstance!=null) {
          historicTaskInstance.setTaskDefinitionKey(this.taskDefinitionKey);
        }
      }
    }
  }
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I have HistoryLevel set to "Audit"  to track variable changes. But what is the sense of above code? Variable "historicTaskInstance" isn´t used in this function.
(or is there some MyIbatis magic?).

Is there a way to improve my query without the N additional SELECT statements?

Kind regards
Philipp Eichhorn

[frederikherema1]

What version are you using? I discovered this a while ago and it was fixed:
http://jira.codehaus.org/browse/ACT-766

If you're using the latest version and you're still seeing this problem, let me know…

[pcsquirrel]

its v5.6

i searched the forum but not i JIRA so I haven´t found the bugentry.

I had a look on the changes Tom Baeyens made to fixe the issue. He introduced "set*WithoutCascade" methods for MyBatis. he made this for a couple of properties, but not for "taskDefinitionKey" which still triggers the query.

it is maybe also necessary for "setTaskDefinition" but I´´m not sure.

I will try to extend the patch and will report

philipp eichhorn

[pcsquirrel]

I have done the following patch


Index: java/org/activiti/engine/impl/persistence/entity/TaskEntity.java
===================================================================
— java/org/activiti/engine/impl/persistence/entity/TaskEntity.java (revision xxx)
+++ java/org/activiti/engine/impl/persistence/entity/TaskEntity.java (working copy)
@@ -493,7 +493,11 @@
     this.parentTaskId = parentTaskId;
   }

+  public void setTaskDefinitionKeyWithoutCascade(String taskDefinitionKey) {
+     this.taskDefinitionKey = taskDefinitionKey;
+  }    
   public void fireEvent(String taskEventName) {
     TaskDefinition taskDefinition = getTaskDefinition();
     if (taskDefinition != null) {
Index: resources/org/activiti/db/mapping/entity/Task.xml
===================================================================
— resources/org/activiti/db/mapping/entity/Task.xml (revision xxx)
+++ resources/org/activiti/db/mapping/entity/Task.xml (working copy)
@@ -69,7 +69,7 @@
     <result property="executionId" column="EXECUTION_ID_" jdbcType="VARCHAR" />
     <result property="processInstanceId" column="PROC_INST_ID_" jdbcType="VARCHAR" />
     <result property="processDefinitionId" column="PROC_DEF_ID_" jdbcType="VARCHAR"/>
-    <result property="taskDefinitionKey" column="TASK_DEF_KEY_" jdbcType="VARCHAR"/>
+    <result property="taskDefinitionKeyWithoutCascade" column="TASK_DEF_KEY_" jdbcType="VARCHAR"/>
     <result property="dueDateWithoutCascade" column="DUE_DATE_" jdbcType="TIMESTAMP"/>
   </resultMap>


it seems to work, but I haven´t run the testsuite against it.

philipp eichhorn

[jsissom]

Task queries still have a N+1 select bug with the default history level.  Can this patch be included in v5.8?

[frederikherema1]

Applied the patch to trunk