How is clustering in Acitivti 5.X different from JBPM 5.X?

Question

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.

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?

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?

Answer 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.

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.

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.

Works like a charm...