The scenario that I basing this on
我基于的场景
Load Balancer
|
------------------------------------------
| | |
Node 1 Node 2 Node 3
| | |
------------------------------------------
|
Common Database
Node 1, 2 and 3 will have their own singleton instances of a Process Engine. All servers are in an Active-Active configuration which means requests are routed to each node in a more or less round robin manner.
节点1、2和3将拥有自己的流程引擎的单例实例。所有服务器都处于活动-活动配置中，这意味着请求以一种或多或少的轮循方式路由到每个节点。
Scenario 1 A request is routed to Node 1 which starts a process with the id 100. Activiti flushes this state immediately to the database. Another request is routed to node 2 where a user may want to carry out a human task (such as approve) on the process instance with same id i.e. 100. Although the process instance is not in memory of the 2nd node if the process engine on this particular node queries the database it will get it, load it and allow the user to carry out the task. So there is no issue. However since JBPM 5.4 does not flush it's state immediately to the database this will cause issues. Am I right?
场景1请求被路由到节点1，节点1启动id为100的进程。Activiti立即将该状态刷新到数据库中。另一个请求被路由到节点2，其中用户可能希望在具有相同id(即100)的流程实例上执行人工任务(例如approve)。尽管流程实例不在第二个节点的内存中，但如果这个特定节点上的流程引擎查询数据库，它将获取它、加载它并允许用户执行任务。所以没有问题。然而，由于JBPM 5.4没有将其状态立即刷新到数据库中，这将导致问题。我说的对吗?
Scenario 2 This is a maker checker scenario. Two checkers are logged into Node 1 and Node 2 respectively. The first checker approves an work item. The second checker approves the same work item. How does Activti handle this?. Will it throw an exception or will it behave in a idempotent manner and allow both the operations to succeed? And How does JBPM handle this?
场景2这是一个maker检查器场景。两个检查程序分别登录到节点1和节点2。第一个检查器批准一个工作项。第二个检查器批准相同的工作项。Activti如何处理?它会抛出一个异常还是以幂等的方式运行并允许两个操作都成功?JBPM如何处理这个问题?
1 个解决方案
#1
1
hope this answer is not to late.
希望这个答案不会迟到。
We use activity in a clustered environment and it works pretty well without doing anything. From scratch Activiti engine is made to work on clustered mode. There is no extra configuration to be done. Just create multiple process-engines (on machine or multiple machines don't care) and connect them to the same database. All process engines connected to the same db communicate with each other (using the db) and handle by themselves.
我们在集群环境中使用活动，它在不做任何事情的情况下工作得很好。从scratch Activiti引擎到工作的集群模式。没有额外的配置要做。只需创建多个进程引擎(在机器上或多台机器上不需要)并将它们连接到同一个数据库。所有连接到相同db的进程引擎都彼此通信(使用db)并自己处理。
Also Activiti documentation / forum says there is no specific need or work to do because activity itself is thread safe even on a clustered application. We use the approach described above for more than 6 months on production now and don't have issues with it.
Activiti文档/论坛还表示，没有特定的需求或工作需要做，因为即使在集群应用程序上，活动本身也是线程安全的。我们使用上面描述的方法已经超过6个月了，并且没有问题。
Before starting the process you schooled check if this process has already been started for the same id (e.g. 100) just to be sure. but you can also check inside your workflow and throw an error that this has already been processed.
在开始这个过程之前，你要先检查这个过程是否已经开始了(例如，100)，以确定。但是您也可以检查您的工作流并抛出一个已经处理过的错误。
Works like a charm...
就像一个魅力……
#1
1
hope this answer is not to late.
希望这个答案不会迟到。
We use activity in a clustered environment and it works pretty well without doing anything. From scratch Activiti engine is made to work on clustered mode. There is no extra configuration to be done. Just create multiple process-engines (on machine or multiple machines don't care) and connect them to the same database. All process engines connected to the same db communicate with each other (using the db) and handle by themselves.
我们在集群环境中使用活动，它在不做任何事情的情况下工作得很好。从scratch Activiti引擎到工作的集群模式。没有额外的配置要做。只需创建多个进程引擎(在机器上或多台机器上不需要)并将它们连接到同一个数据库。所有连接到相同db的进程引擎都彼此通信(使用db)并自己处理。
Also Activiti documentation / forum says there is no specific need or work to do because activity itself is thread safe even on a clustered application. We use the approach described above for more than 6 months on production now and don't have issues with it.
Activiti文档/论坛还表示，没有特定的需求或工作需要做，因为即使在集群应用程序上，活动本身也是线程安全的。我们使用上面描述的方法已经超过6个月了，并且没有问题。
Before starting the process you schooled check if this process has already been started for the same id (e.g. 100) just to be sure. but you can also check inside your workflow and throw an error that this has already been processed.
在开始这个过程之前，你要先检查这个过程是否已经开始了(例如，100)，以确定。但是您也可以检查您的工作流并抛出一个已经处理过的错误。
Works like a charm...
就像一个魅力……