It is possible to disallow concurrent execution of a microflow. More information about that:
“the user receives a message or another microflow is executed instead.”
I hope this helps!
If you need semaphore functionality (MF's queue up before the semaphore and only one by one they are allowed to pass) to prevend critical sections executed in parallel by different threads, Mendix does not support that out-of-the-box. The "Disallow concurrent MF execution" does not give that functionality. The Java synchronisation and locking facility also does not give that functionality, because this only works in Java code and not on MF's.
There are two options:
1 – Create semaphore functionality in Java yourself (java.util.concurrent.Semaphore). Make two Java actions to acquire and release the semaphore. In the MF acquire the semaphore before the critical section and release after. You have to guarantee a release (proper exception handling), otherwise you have a deadlock.
Important: this only works within one JVM. In the case of horizontal scaling and multiple JVM's it does not work. Even so the Disallow concurrent MF does not work in that scenario either.
2 – In scenario of horizontal scaling you need the database to help with this. It is more expensive in performance, but is the only way to guarantee thread synchronisation over JVM's. An update to the same record will hold any other update to that same record by other database sessions (from other threads) until commit or rollback. Also the uniqueness constraint when creating the same unique value will hold any other session from creating. These properties of the database you can use to acquire and release a lock.
You could also look for “Pessimistic locking” module in appstore if you need another functionality of locking, a signalling to other users that same data is under maintenance by somebody else.
How about the process queue, that should be able to deal with a First-in-first-out mechanism by assigning a process to a single threaded queue.
You could also try to build something using the Java action commit in separate transaction from the community commons that way the number update can be commited at the beginning of the microflow.