I did not see the comment the first time, so my bad

The performance shouldn’t be an issue if there aren’t many open tasks for a given process instance. But it happen sometimes and than a simple Hibernate query does the trick much faster than iterating over the collection.

Regarding your ‘remark’… look at my comment in the code but….

What happens is that the token for the specifically configured task-node is retrieved (task-node a) with

TaskNode taskNode = (TaskNode) node;

Token token = (Token) executionContext.getToken().getParent().getChildrenAtNode(taskNode).get(0);

(assuming there is only one token created in task-node a)

and within that tasknode (token) the unfinished tasks on that token are retrieved with

Iterator unfinishedTasks = executionContext.getTaskMgmtInstance().getUnfinishedTasks(token).iterator();

So I do not think there is a problem if there are parallel tasks, but I’ll extend my testcase that I HAVE to write to get it included in jBPM with an additional branche in the fork and see what happens.

Regarding performance (regarding the code above that is?), I did not look into that (yet) but since it happens not that often, I’m not inclined to look into it yet. Maybe an index on something will help out.

I agree that some parts should be incorporated into the distribution (CreateTask/CancelTask classes … I’ve written them myself too in the past… )

I’m hoping that the WF pattern lovers once will see that (with a little creativity) many (if not all) patterns can be supported by jBPM.

My only remark is for the CancelTask: if there are other parallell paths which contain unfinished tasks, they are cancelled too…

For performance reasons, I would do a Hibernate call for retrieving the specific TaskInstances with the given name which are open.

Looking forward to the next post!