Hi Omar,
Commit in Mendix act more like a ORM “flush”…
This is because you may have a complex microflow with sub-microflows or even multiples commits in same flow. To prevent garbage in database or extras activities to “rollback/delete” in case that something goes wrong, all changes are only “commited” in the end of a transaction/microflow.
Basically:
For each microflow we have a transaction: start → savepoint, [ … activities … ], end → db commit or rollback.
If we have submicroflows with Error handling [ … activities .. sub .. activities ] we may have a sub-transaction with savepoints [activities] commit… etc
Its based on flow direction, activities and Error Handling Types in it!
Check the Error handling for more details / use cases:
https://academy.mendix.com/link/modules/175/lectures/1345/6.2-Error-Handling-Types
https://docs.mendix.com/howto/logic-business-rules/set-up-error-handling/#41-default-error-handling
Best regards
Probably because Mendix chose or needed to make microflows always be a single transaction. Meaning that at the end of the microflow, either every database change is saved or none at all.
Committing a Mendix commit immediately, even halfway the microflow, Mendix would need to arrange complex write-and-read-locking procedures to keep it a transaction.
There is not really a use-case for it, just this technical transaction reason.