Issue

A single entry, such as an invoice or order, may disappear from the database after a user logs out or a session expires, even though it previously moved through multiple workflow stages and was visible to several users. This pattern—where only one record is lost, not the entire table—strongly indicates autocommit cleanup. The issue occurs when an object is auto-committed due to an association but is never explicitly committed. As a result, the record can be processed and seen by others while the session is active, but is deleted when the session ends.

Environment

Studio Pro (all versions)

Cause

Mendix uses an autocommit mechanism to maintain referential integrity in the database. When a parent object is explicitly committed, any associated child objects that have not been explicitly committed in the same transaction are automatically saved to the database by the Mendix runtime. 

When an object is autocommitted, Mendix performs the following operations:

• Writes the object — including all attribute values — to its corresponding entity table in the database (for example, YourModule$YourEntity)
• Writes all association records to their respective association tables in the database
• Inserts a tracking row into system$autocommitentry to mark the object as saved to the database but not yet explicitly committed

While the originating session remains active, the autocommitted object is fully retrievable by all users and behaves identically to an explicitly committed record. This is why the record appears to progress through multiple workflow stages and approvals — it genuinely exists in the database for the duration of that session.

However, when the session that created the autocommitted object ends — through a normal logout, a timeout, or an unexpected disconnection — Mendix automatically removes all rows for that session from system$autocommitentry and deletes the associated objects from the database. This removal happens regardless of how many workflow stages or users have already interacted with the record.

The application logs will contain lines similar to the following when this occurs:

WARNING - Core: Some autocommitted objects still existed on logout for session '<session-id>'.
Autocommitted objects are newly created objects which were not yet committed, but are inserted
into the database because an associated object was committed.
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 sessionWARNING - Core: Some autocommitted objects still existed on logout for session '<session-id>'.
Autocommitted objects are newly created objects which were not yet committed, but are inserted
into the database because an associated object was committed.
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

Solution / Workaround

To prevent data loss caused by autocommitted objects, ensure that all objects are explicitly committed at every stage of the workflow where they must persist independently of any user session.

Additional information

• Mendix documentation: Committing Objects — Autocommit and associated objects