Could multiple Activiti engines share one Repository?

[mscai]

If multiple Activiti engines share one Repository DB, are there any issues?
In this environment, could each Activiti engine work independently?
In this environment, how could I query tasks, process instances which belong to the current activiti engine? It seems ProcessInstanceQuery and TaskQuery don't  provide this functionality.

My use case is a HA system. There are some active processes. Each process contains one activiti engine, and execute workflow. There are other processes which are called as backup processes. These processes do nothing. If one active process crashes, there would be backup process selected. This backup process takes up the responsibility of the crashed active process. It start a activiti engine and continue to execute workflows.

My rough idea is each activiti engine contains an unique processEngineName. All activiti engine share the same repository DB. And each of them works independently. If one process crashes (its activiti engine must crash), the selected backup process starts a activiti engine with the same processEngineName, and then continue.

[trademak]

Hi,

Yes Activiti is cluster friendly. There is no code other than the job executor that requires specific logic to support clustering.
When all cluster nodes point to the same database, it should work fine.
Are you also not planning to use the async continuations functionality? Because that requires the use of the job executor as well.

Best regards,

[arvin_wang]

hi, guys

      suppose this case: i have two engines(engineA and engineB) deployed on two nodes(nodeA,nodeB) respectively. and the
two engines share one db. is it possible that the jobExecutor created by engineA only fetches  the process jobs started by engineA and jobExecutor created by engineB only fetches the jobs started by engienB?

[chris_joelly]

what do u mean with "jobs started by engineA" ?

i think every engine's job executor will 'start' all jobs it finds in the database. So they will run on all machines concurrently. Imagine a start-timer-event, which starts a process instance. You will get process instances of the same process definition on all nodes, and if these process instances work on the same data, eg. JPA entities, you will probably run into a messy situation.

Another tricky thing is when you have asymmetric clusters, i mean not all machines have access to the same resources and the process instances rely on specific resources. If you do not start process instances via start-timer-events you can control where they are executed. But with timer-boundary-events it might happen that execution continues on a node which does not have access to a needed resource.

At least this is what i assume would happen in a clustered environment together with the standard JobExecutor…

[meyerd]

As Tijs points out, you can have multiple intances of the activiti engine running against the same database.

In such a scenario, the job executor of each activiti instance will poll the database for jobs. The jobexecutors will make sure that each job is only executed once (sucessfully). To give this guarantee, the jobexecutor locks jobs in the database.
To come back to your scenario, if you have a job executor active on nodeA and a job executor on nodeB and there is a single job in the database, the job will either be executed by nodeA or node B.

If executing the job requires access to external resources (java classes, persistence units etc…) provided by the environment, you must make sure that these resources are available on each node.

See also:
https://app.camunda.com/confluence/display/foxUserGuide/Job+Execution

[arvin_wang]

"jobs started by engineA" means jobExecutor in engineA only gets the jobs created by engineA from the db.
now i want to add a field in table JOB distinguishing jobs of different engines. i do not know whether it is ok.

another demand: i want to suspend or activate a executing process instance, but the APIs provided by
activiti (such as suspendProcessInstanceById, etc) seem not to satisfy. btw, the process instance contains
many serviceTasks and these serviceTasks are set asyc.