Debugging autocommitted objects

Recently we are receiving more incidents that production data magically disappears from multiple applications. After researching we found out that the missing data is related to objects that are removed from the database due to the auto-committed 'feature' from Mendix. We could determine this based on the warning about the auto-committed objects on logout of a user session. So now that we know from the log message the data is deleted because of auto committing, and we also know which objects and how many are auto committed, it is still not always trivial to find and fix the cause. How can we, in a big and complex project, in a structural way, find our missing commit actions ? For debugging this behaviour I really miss more information for example a path in the log message showing the 'stacktrace' like: Object 'x' is autocomitted as a result of a commit of object 'y' in flow 'Module.CommitY' But maybe more important I would like to find a way to prevent this behaviour, for example by a error or warning in Mendix if the 'wrong' commit behaviour is detected.    
3 answers

Auto commit entries are stored in the following table: system$autocommitentry

You’ll find there the ids of autocommitted objects and eventually the type of objects that are not properly committed.

Then you just need to search where those objects are created in the model and ensure they are explicitly committed.

In my case, they were caused by the ExcelImporter when I generate templates directly from the model instead of using the UI.



The issue isn't the autocommit feature, but the lack of correct committing in your own model.
โ€‹Autocommit does only exists to ensure that when you commit an object (owner of the association) with a reference to a not (yet) committed object to ensure that the association is correctly stored in the database.
BUT you still need to commit the autocommitted object. Never ever trust the autocommit as a full commit.
So when dealing with referenced data in a microflow, commit everything in a commit activity explicitly.

I guess that the lognodes connectionbus_Update and/or DataStorage_QueryHandling  will provide info about autocommits



Trace back to the microflow where the data got changed and commit the data right then and there.

Autocommit is a (too) complex feature that often leads to unexpected results. Therefor it is a good thing that autocommit is about to get replaced by something better (hopefully), see
You might want to upvote that idea.