querying usertask's in servicetask

[mindaugas]

Hello everyone,

I have one question: it is possible using taskService.createTaskQuery() select tasks which is not delegate for deleting?

I have service task (which goes after UserTask) for completing other active UserTasks. So when querying for active usertasks in result list I get the task with mark ((TaskEntity)task).isDeleted()=true I think this task should not be in result list?

Trying complete this task exception throws:
org.activiti.engine.ActivitiException: this activity doesn't accept signals
   at org.activiti.engine.impl.bpmn.behavior.FlowNodeActivityBehavior.signal(FlowNodeActivityBehavior.java:53)
   at org.activiti.engine.impl.bpmn.behavior.AbstractBpmnActivityBehavior.signal(AbstractBpmnActivityBehavior.java:90)
   at org.activiti.engine.impl.persistence.entity.ExecutionEntity.signal(ExecutionEntity.java:353)
   at org.activiti.engine.impl.persistence.entity.TaskEntity.complete(TaskEntity.java:157)
   at org.activiti.engine.impl.cmd.CompleteTaskCmd.execute(CompleteTaskCmd.java:39)
   at org.activiti.engine.impl.cmd.CompleteTaskCmd.execute(CompleteTaskCmd.java:24)
   at org.activiti.engine.impl.cmd.NeedsActiveTaskCmd.execute(NeedsActiveTaskCmd.java:58)
   at org.activiti.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:24)
   at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:60)
   at org.activiti.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:42)
….


Regards,
Mindaugas

[gokceng1]

I couldn't totally get your problem but you can not signal user tasks, user tasks can be completed not signaled. You can signal receive tasks.

[mindaugas]

for example service task implementation:



        TaskQuery query = taskService.createTaskQuery();
        query.taskAssignee(assignee);
        List<Task> tasks = query.list();
            for (Task task : tasks) {

                    if (task instanceof TaskEntity) {
                        if (!((TaskEntity) task).isDeleted()) {
                            taskService.complete(task.getId(), taskParams);
                        } else {
                            //should not be this, but sometimes comes
                            log.debug(" ((TaskEntity)task).isDeleted() = true");
                        }
                    } else {
                        taskService.complete(task.getId(), taskParams);
                    }



it's possible in query avoid this situation "((TaskEntity)task).isDeleted() = true" ?

Mindaugas

[jbarrez]

The reason for that is that Activiti flushes the transaction at the end. So basically what you are seeing is data which is not yet committed to the database.

[mindaugas]

hi, jbarrez,

I am little confused, I think that usertask completion and next coming servicetask execution is in the same transaction or not? So basically if it is the same transaction,after task is deleted this task should not be in select result (if task deletion and selection is in the same transaction)? Does querying task acts like different transaction ?


It's possible avoid the data which is not yet committed to the database?

Mindaugas

[ronald_van_kuij]

It's possible avoid the data which is not yet committed to the database.

Is this a question or a statement?

[mindaugas]

Is this a question or a statement?

Question.

[frederikherema1]

As joram said, the entity-updates are only flushed at the end of the transaction to the database. So the task-delete is still "pending" by the time the service-task is executed. Since all queries in the API run against the database, the task will be still visible.

Anyway, completing tasks for the current flowing process in a service task is a BAD IDEA, since it could mess up executions. A user-task should be finished by a user (using the API completeTask externally). If you want your service-task to influence existing tasks, better to model a subprocess around it with a boundary-error event or message-event. This is also more clear for people reading the process.