But we also have definitions that we want to share between nodes (no tenant identifier). This seems to be well supported and we can make each process engine deployment aware. And when each engine is started, we can registrar the deployments for each tenant (node).
I have also seen that we can implement a TenantIdProvider that will allow us to set the tenant id for the process instance when it is created. I would think this would isolate this instance to the tenant specified.
What I want to know, is if there is a way to isolate the job acquisition to the tenant of that node even for these shared definitions? It seems that the registration for the job executor is by deployment, not by tenant. So these shared definitions have the ability to jump to another node if the job acquisition picks up the work.
As an addition, we don’t want to isolate the tenants by schema or database because new nodes can be created at any time and it would be problematic to create new tables on the fly.
As of now, there is no feature I am aware of that makes the job executor “tenant aware”.
Shared process models are by definition expected to run on every node in the cluster and might be partially executed by every node. The only way to bind them to a node is by deployment awareness, e.g. by making them part of the specific process application or by registering a deployment to an application and therefore the job executor bound to it.
Could you explain in a bit more detail why this behavior does not suit your needs at the moment (e.g. unexpected load on nodes that execute jobs of instances started on other nodes etc.)?
That said, one way around this I can think of right now would be to include the “shared definitions” in all applications and attach the respective tenant id to them. Thereby, they are
available on every node (a tenant can only see the version of that “shared definition” that is bound to his/her id),
bound to and executed on the separate single nodes (and their job executors) they “belong to”.
Technically, those definitions would not be considered “shared” anymore, but still be available everywhere. Furthermore, this might of course introduce more organizational overhead in terms of keeping track of versions and resources for all the applications, depending on the nature of those shared definitions.
Despite that, you are of course welcome to open a feature request in our Issue Tracker to initialize the addition of such a feature in the engine.
