在jBPM中，任务的分配有两种模式：

1. 推（Push）模式    在这种模式下，系统计算出应该由哪个参与者(actor)完成当前任务(task)，然后直接将此task送到该actor的任务列表中(tasklist)；
2. 拉（Pull）模式    在这种模式下，系统首先计算出应该由哪个参与者池(pool of actors)完成当任务，并将该任务送入相应的任务池中；然后，再由参与者池中的任一人将任务拉到自己的任务列表中。

参与者池与角色、用户组的差异

一般的应用中，角色与用户组的概念比较常见，而参与者池则不常见。

针对一个Task一般会有多个可能的操作，而不同的角色有可能有权限进行其中的一部分或全部操作。所以，不同角色有可能属于相同的参与者池，一个角色也有可能被加入到多个参与者池中。

一般用户组是按组织架构进行划分的，在同一个用户组可能会有多个不同的角色，或者具有不级别的权限。即使将同一角色、具有同一级别权限的用户划分为一组，也不能回避具有更高级别权限的用户操作低级别工作任务项的情形。另一方面，在Multi-Entity架构下，也存在跨Entity操作的情形。

总而言之，参与者池是区别于按角色、按组织进行划分的、一种特别的用户分组方法。换言之，参与者池其实也是可以预先定义的。

何时进行任务分配计算

既然参与者池是可以预见的，那么在“拉模式”下，何时进行任务分配计算呢？

毫无疑问，在工作流系统中，计算是在任务状态转换时自动完成的。（当然，相对于应用的事务提交，工作流的这些操作都可以是异步完成的。）

因些，“拉”的含义，不是在用户刷新任务列表时才去计算他/她的所有工作项；恰恰相反，无论是“拉”或是“推”，工作流系统其实都预先计算好了参与者的任务列表或可以从中挑选任务的“任务池”。

jBPM参与者池的数据库设计

jbpm_taskinstance与jbpm_pooledactor是典型的“多对多”的关系，中间通过jbpm_taskactorpool拆分成两个“一对多”。