Hi,
Is there any way to enforce sequential execution of process instances with same business key? Problem occurs if we have multiple process instances with the same business key updating the same row and throwing optimistic locking exceptions. We can’t have the business key to be unique per process instance
Multiple processes with the same business key should not be a problem at all; it’s not required to be unique. What row is being updated? Is it a row in your custom DB? In this case you’ll have to provide a synchronization mechanism.
I don’t think it’s possible to enforce sequential execution of different process instances.
Business key column doesn’t have any constraint unless if you have explicitly executed the query to make that column as unique.
Are you passing payload array to start the process with same business key? In that case, you can model a process with embedded subprocess with multi-instance and sequential markers. It can be handled in multiple ways.
@aravindhrs No, we are not passing an array of payload with the same business key. I start the process instance when I receive a message from Kafka. And it could happen that these messages are far between. Hence I am not sure when I will be starting these instances. In this case, I wouldn’t be able to proceed with the approach you suggested.
Hi,
I would suggest the pattern you want is a ‘critical section’ much like in multi-threaded programming. Here’s a process model which achieves a critical section…
The critical piece is how to implement the semaphore. In a single node JVM, you could use a plain old java semaphore. However, in a cluster you need a network semaphore. In addition, you really need a semaphore per active business key. You could use a custom DB table and write and delete the business key to a unique index - hence if you cant write, you throw a BPMN error to send the process instance to wait for a semaphore release signal. Another way to achieve this is to query the runtime for all active process instances with the same business key and order them by start time. If this process instance is not the earliest instance with this business key, then throw the bpmn error to send it to wait for an earlier one to complete. When the earlier one completes it will throw the release signal which could be correlated along with the business key… Note with this latter approach, you have to ensure you have sufficient async tasks to force a DB flush so that the DB can act as a semaphore…
regards
Rob
