Acitivti 5.X中的群集与JBPM 5.X有何不同?

时间:2014-02-23 10:10:07

标签: jbpm activiti

我基于

的情景
             Load Balancer
                     |
------------------------------------------
|                    |                   |
Node 1             Node 2              Node 3
|                    |                   |
------------------------------------------
                     |
               Common Database

节点1,2和3将拥有自己的Process Engine单例实例。所有服务器都处于主动 - 主动配置,这意味着请求以或多或少的循环方式路由到每个节点。

情景1 请求被路由到节点1,节点1启动ID为100的进程。 Activiti立即将此状态刷新到数据库。另一个请求被路由到节点2,用户可能希望执行人工任务(例如批准)在具有相同id的流程实例上,即100.虽然流程实例不在第二个节点的内存中,但如果此特定节点上的流程引擎查询数据库,它将获取它,加载它并允许用户执行任务。所以没有问题。 但是,由于JBPM 5.4不立即将其状态刷新到数据库,这将导致问题。 我是对的吗?

情景2 这是制造商检查方案。两个检查器分别登录到节点1和节点2。第一个检查员批准工作项目。第二个检查员批准同一个工作项。 Activti如何处理此事?。它会抛出一个异常还是会以幂等方式运行并允许这两个操作成功? 以及JBPM如何处理这个问题?

1 个答案:

答案 0 :(得分:1)

希望这个答案不要迟到。

我们在集群环境中使用活动,它可以很好地工作而不做任何事情。 从头开始,Activiti引擎可以在群集模式下工作。 没有额外的配置要做。只需创建多个流程引擎(在机器上或多台机器上都不关心)并将它们连接到同一个数据库。 连接到同一个数据库的所有进程引擎相互通信(使用数据库)并自行处理。

此外,Activiti文档/论坛表示没有特定的需要或工作要做,因为即使在集群应用程序上,活动本身也是线程安全的。 我们现在使用上述方法生产超过6个月,并且没有问题。

在开始这个过程之前,你要学习检查这个过程是否已经为相同的id(例如100)启动,以确保。但您也可以检查工作流程内部并抛出已经处理过的错误。

像魅力一样......