A few question about depolying multiple instances of flowable task

Flowable Engine
1

At the begining, English is not my native language; please excuse typing errors.

Original Question

We are looking for a method for deploying multiple instances of flowable-task. However, it seems not clearly about this kind of possibility in the documentation of flowable-engine 6.0 release. Would you please help to give me any advice about doing this?

My question is the potential problems in this scenario. Such as data consistency in cache if flowable cache data in DAO or lack of optimistic lock in SQL.

Any suggestion would be appreciate. Thanks ahead!

I’m new to flowable and I know I could get any detail in source code thanks to this wanderful opensource project. However, I’m eager to know whether flowable support this kind of scenario. Of course, I’ll keep finding the solution to support this if it could not support this feature temporarily. Thanks again!

Several Questions

After hours deep learning in source code, it seems not secure running multiple instances of flowable-task at same time binding to the same data source. There are several resons as following:

  1. Not all update/delete operations are lock protected, such as deleteByteArrayNoRevisionCheck and updateExecutionTenantIdForDeployment. Although it seems secure if delete is not so important and changing tenant will always work for last modification. While, if two users are updating the tenant, which should work could always confuse;
  2. Native cache for entities are enabled by default, such as DbSqlSession#selectList, this should be at some risk;
  3. If there are multiple instances running at different machine, how could I decide which one should be taken into consideration? And what’s more, these two instances are used for load balance, how could flowable choose the right one? And if one of them down, how do flowable know switch to another one?

About Load Balancing

  1. My solution is using distributed service framework, such as dubbo, which need additional development of course. The easiest way to do that is developing a layer based on flowable rest. Is that the best practice?