Hi, There's something I don't fully understand. From my application, randomly an object is being deleted. I'm using Mx version 9.24.16 Here's the error message: 2024-05-14T04:12:50.297337 [APP/PROC/WEB/0] WARNING - Core: Some autocommitted objects still existed on logout for session 'xxx@xxx.com'.2024-05-14T04:12:50.297356 [APP/PROC/WEB/0] Autocommitted objects are newly created objects which were not yet committed, but are inserted into the database because an associated object was committed.2024-05-14T04:12:50.297362 [APP/PROC/WEB/0] Autocommitted objects should explicitly have been committed, please check your model and apply the necessary changes. The autocommitted objects have been deleted from the database to prevent database corruption.Number of autocommitted objects per type which still existed for this session:2024-05-14T04:12:50.297375 [APP/PROC/WEB/0] - xxx.xxx: 1 object(s).2024-05-14T07:40:06.645243 [APP/PROC/WEB/0] ERROR - Connector: null 1. I'm creating the object, but I'm not committing it. It has the state: 'autocommitted'. That is fine. Then after a while, the object IS committed and has the state: 'normal'. To me this means that the object should never be turned into the state of 'autocommitted' again, because it already has been successfully committed to the database once? ...Is that correct? 2. Will my problem be solved if I commit the object immediately when I create it? ...Or, can it change to 'autocommitted' again? 3. If Mendix is deleting 'autocommitted' objects that at some point were in the 'normal' state, but changed to 'autocommitted' for whatever reason (personally I think it should not be possible to change them to 'autocommitted' anymore), would that not be very dangerous? 4. Relating to my application, I'm not able to reproduce it, because it happens randomly. Could it have to do with session time out? Is a 'Sign out' action from closing the session any different from a manual Sign out action? 5. Here's another question related to the topic: https://community.mendix.com/link/space/databases/questions/93802
asked
Sebastiaan van der Plaat
3 answers
1
Hi Sebastiaan,
Autocommit issues are usually very hard to reproduce, but thusfar i was never able to pinpoint Mendix doing anything wrong here. The root cause is normally that the app is not careful in committing/rolling back everything properly at the required moments. For example when there is an edit-page with a save-button, but also a menu that allows the user to navigate away from the page without pressing the save-button first. Or an edit page where multiple objects are modified at the same time and pressing save forgets to commit every object that was modified. But there are many other ways.
In any case, i would not expect Mendix to delete anything automatically that was properly committed first. If you can reproduce that, i would suggest upgrading to the latest version of Mendix first. And if it still happens there: raise a ticket with Mendix support.
I hope this helps.
Michiel
answered
Michiel Arts
0
Hi Sebastiaan,
I think that the logout for session 'xxx@xxx.com. is causing the behaviour of the App. If the user closes his/her browser, closes the laptop, or the system is reset, the session is closed before the microflow reaches the endpoint. This is causing Mendix to roll back the unfinished microflow and remove the autocommitted objects. If the microflow under the save button is taking a lot of time to process, the change that this is occurring increases. If your logic allows, consider using a task queue. The interaction between the user pressing the save button and putting the task in the queue is very short. The actual task is running unattended in the background.
Go Make It
answered
Marco Spoel
0
Hi Sebastian,
autocommitted objects often show up in one-to-one associations. If you create an object (say B) and link it 1:1 to another object (A), then commit A but forget to commit B, Mendix will autocommit B behind the scenes. If that autocommitted object is later replaced or never explicitly committed, it may be deleted — for example, during logout or session timeout.
To avoid this, always explicitly commit or delete both sides of a one-to-one association.