Creatiing new pooled actors for every task instance

[stringaling]

Hi,

I have noticed that for every new task instance that contains an assignment to a pooled-actor within a process, there are new entries added to the jbpm_pooledactor table.

This behavior is a wee bit undesirable, as we end up creating a rapidly growing large table with very redundant records.

The table contains a 'VERSION_' field which would seem to indicate that at least some thought might have been put into doing this differently.

Is there any plans to work on assignment in upcoming releases ? Or is this just how it is going to work for a while ?

Example of my assignment:

 <task name="Manual Address Review">
 <assignment pooled-actors="WD User"/>
 </task>

(The same behavior exists with swimlanes)

The source of my concern is trying to improve performance when getting a task list for when there are a large number of outstanding tasks. The number of joins required to do this is expensive, and could possible be reduced if there was a consistent ID for pooled actors in the JBPM_POOLEDACTOR table.

(Couldn't these assignments, actors be determined and setup at the time of process deployment, rather then as part of creating a task instance ?)

Thanks,
David Stringer

(Jboss 4.0.5, Jbpm 3.2.2, Java 1.6, Oracle 10g)

[kukeltje]

David,

Deciding assignments at the time of deployment is a totally wrong approach. Things might change while running the process. The pooled actors for a taskinstance might different to another instance although refering to the same swimlane. It certainly does for most of the processes we've created.. So each taskinstance having it's own pooled-actors, or refering to a swimlane is imo the right approach. That using swimlanes does not reduce it, by having e.g. the swimlanes for a processinstance refering to the pooled-actors table might be considered an 'issue' although I'm not to familiar with the internal workings of this part.

Do you have an example of the number of joins? Since (without looking at the query) my impression is that it is not to bad.

[stringaling]

I have no issue with assignment at run time. In my mind the assignment is the join between the JBPM_POOLEDACTOR, and JBPM_TASKINSTANCE via the JBPM_TASKACTORPOOL.

Where I have issue is creating assignee's (POOLEDACTOR) when there are defined as part of the process definition. The fact that I declare a swimlane that defines a pooled_actor such as:

 <swimlane name="Fraud">
 <assignment pooled-actors="Fraud User"/>
 </swimlane>

would be a pretty good indication that this not going to change.

OK - I do understand that the list of pooled-actors can be determined at runtime via an expression, and in this case there is a need to store the actor at run times. But then why bother with the MANY-TO-MANY join then. Why not put the instance_id directly on the JBPM_POOLEDACTOR table. The same functionality could be achieved then with 2 joins instead of 3.

Here is an example of the query:

 <query name="TaskMgmtSession.findPooledTaskInstancesByActorId">
 <![CDATA[
 select distinct ti
 from org.jbpm.taskmgmt.exe.PooledActor pooledActor
 join pooledActor.taskInstances ti
 where pooledActor.actorId = :swimlaneActorId
 and ti.actorId is null
 and ti.isSuspended != true
 and ti.isOpen = true
 ]]>
 </query>

(from hibernate.queries.hbm.xml)

What the query hides is the MANY-TO-MANY table that is part of the hibernate mapping definition:

...
 <set name="pooledActors"
 cascade="all"
 table="JBPM_TASKACTORPOOL">
 <key column="TASKINSTANCE_" foreign-key="FK_TASKACTPL_TSKI"/>
 <many-to-many class="org.jbpm.taskmgmt.exe.PooledActor" column="POOLEDACTOR_" />
...
 </set>

(from TaskInstance.hbm.xml)

 <set name="taskInstances" inverse="true" table="JBPM_TASKACTORPOOL">
 <key column="POOLEDACTOR_" foreign-key="FK_TSKACTPOL_PLACT"/>
 <many-to-many class="org.jbpm.taskmgmt.exe.TaskInstance" column="TASKINSTANCE_" />
 </set>

(from PooledActor.hbm.xml)

The three joins is compounded by a 4th join that I need to do to properly implement paging within our application. :(

[kukeltje]

The pooled actors can, ass you state be more than one id (e.g. as you have in a group). It can also be a list of individuals (I do not advise this to anyone, but it can be done). which can change over time and set via the api. But with your proposal that should still be possible.

What the query hides is the MANY-TO-MANY table that is part of the hibernate mapping definition:

That is why I missed it, I try to stay away as much as possible from the hibernate mappings.

I doubt this will be changed in jBPM 3, but for the task component of jBPM4 it is certainly something to keep in mind (maybe Alex/Tom have already simplified this)

Thanks for the feedback