Question

Prevent concurrent exec of two (or more) microflows

0

Hi, I have microflows M1 and M2, (M3...). I know that I can se concurrent exec. for them to "Disallow", and prevent each from running multiple instances at a time. But, I need to prevent both (or all) of them to run simultaneously. I tried to do this by inserting (and committing) a record right at the start of each microflow. Each microflow also checks if the record exists, before beginning the actual work. When the "work" is done, the microflow deletes this record, and makes the entity (table) empty - allowing other microflow to take over. See the linked image. http://i60.tinypic.com/2ebvla9.jpg link What's happening (I think), is that the "commit" happens only at the end of execution, and M1 obtains a lock on the entity until it's finished. So, although this approach works, it is prone to DB locks. How can I allow commit immediately, without waiting till end of exec? Is there any alternative approach to achieve this (disallow concurrent for many MFs)? Thanks.

asked 2014-08-11

Purandare Amey

7 answers

Sebastiaan van den Broek · Answer 1 · 2014-08-11

That's pretty advanced stuff to express in a microflow, but what if you would have 1 container microflow that is set to disallow concurrent execution and that executes these various microflows for you, picking a specific microflow based on a configuration parameter/entity for example?

Stephan Numan · Answer 2 · 2014-08-11

use the queue module from the appstore?

Chris de Gelder · Answer 3 · 2014-08-11

You can not achieve this by using objects because the way microflows are exectuted is not the sequential as you would expect. Simplified: a set of database queries is created and executed at one moment in time.

You can achieve this by using locks as provided in the community commons module. With a lock you get can unique access to data and preventing others to change that data until you are finished.

Rom van Arendonk · Answer 4 · 2014-08-11

You could use the community commons locking functionality: at server startup, you create a single object, say IsBeingExecuted. Then, when you start one of the three microflows, you use the AcquireLock on that object. When you microflow is finished, you release the lock.

You may need to edit the locking functionality: I believe that locking checks if the user that is requesting the lock is the user that has the lock. This would mean that a single user can execute all three microflows. You would have to edit the functionality so that whenever the IsBeingExecuted object is locked, it doesn't matter which user has the lock, it will always return false.

Purandare Amey · Answer 5 · 2014-08-11

Currently, the insert / commit / delete approach works similar to the "lock" approach, I see that M2 does not start until M1 is finished, and starts afterwards. Without the lock, M2 would have started, and exited the branch - because "goAhead" would be false. But my intent was to avoid this, because it's easy (for future developers ;) ) to make a mistake and possibly create a deadlock.
Having a container microflow is a good solution - except when the triggers are in the UI, which makes it a bit complex to pass parameters to the container guy: M1UIButton --> calls dummy_M1 --> calls container (with param=M1) --> calls M1.
I will checkout the queue app.

Isamu Tanaka · Answer 6 · 2017-06-23

Mendix does not have optimistic or pessimistic concurrency control.

For some application or batch process, queuing is not enough.

Isamu Tanaka · Answer 7 · 2017-06-23

Mendix does not support optimistic or pessimistic concurrency control.

For some application or batch process, queuing is not enough.