Blocked objects commited in microflows until the microflows ends

0
Hi everyone! Here i am again asking for your wisdom.    I've been reading the microflow documentation, and it seems contradictory. It states that the 'commit object' action locks a record until the microflow is complete, but also allows other users to read and modify the previous version of that data while the transaction is ongoing. Any changes made by these other processes will be applied once the initial transaction finishes and the lock is released, overwriting previous changes.   I'm wondering what the standard behavior is in such cases, and if anyone else has run into this issue.
asked
2 answers
1

Hi Daniel,

 

I have not run into an issue with "commit object" yet as I have not yet done multiuser access. But after reading the documentation (Data Storage and Commit Object(s)) I conclude that the behavior is fine.

 

The lock is never applied for reading, only for writing. The writing lock is set when a first commit action in a microflow occurs. Thanks to the behavior of Error Handling the commits to the database happen only at the end of the microflow. This allows for rollbacks during a microflow transaction.

 

Now let's say that two users want to change properties of the same object at the same time. They both read the initial properties and they both change it. One will inevitably click "Save" first and therefore initialize first transaction. Let's also say that the transactions takes really long time to process and while the first transaction is processing the second user clicks "Save" with his properties. As there is a commit action somewhere in the microflow executing the Save action. Write lock will be applied to that specific object with its specific ID, therefore the second transactions needs to wait. After the first transaction is completed with writing new data to database, the second one can proceed. The second transaction finishes with updating the data in the database, overwriting the changes of the first transaction.

 

I see this behavior normal, because no read locks are applied and there isn't any implementation like Git versioning for data in database that would make you resolve the differences.

 

Was this explanation helpful? If not, please clarify what your question is.

answered
1

Hi Daniel, 

 

A question with the same issue is asked here : https://community.mendix.com/link/space/microflows/questions/111718. 

 

 In the answers they offered a few options, but the way I understand it, is because Mendix assumes that conflicts are rare, it uses optimistic concurrency. Basically meaning, that the last commit counts, and allowing others to read and prepare modifications on the 'locked' object. 

So to prevent conflicts, a custom solution must be applied. 

 

Best regards, Stefan. 

answered