Question

How does Mendix handle data consistency and concurrency for Data Grid 2 with XPath under high load?

0

Hi all,In a Mendix application with high data volume and concurrent users, how does the platform internally handle consistency and performance when:A Data Grid 2 uses an XPath datasource with associations, andThe same entities are being updated simultaneously via background microflows / task queuesSpecifically: How does Mendix prevent stale data or race conditions at the client level? Are there any internal optimizations or pitfalls with XPath caching or object locking that developers shouldbe aware of? What architectural patterns are recommended to keep UI data consistent without overusing refreshes or commits?

asked 2026-02-05

Gowtham R

1 answers

Ahmet Kudu · Accepted Answer · 2026-02-05

Mendix keeps data consistency through database transactions. Changes made in a microflow are not visible to others until they are committed. If background microflows run for a long time, they can cause locking and slowdowns. This is expected behavior.

At the client level, there is no automatic synchronization. When data is updated in the background, Data Grid 2 does not refresh by itself. Until a refresh is triggered, users may see stale data. This is normal in Mendix.

An XPath datasource is not cached. Every refresh triggers a new database query. However, XPath queries with many associations can be expensive and hurt performance when data volume is high.

When the same entities are updated at the same time, Mendix follows a “last commit wins” approach. There is no built-in conflict resolution unless you explicitly use optimistic locking or re-fetch data before saving.

The common and recommended approach is to keep UI data simple and stable, do heavy updates in the background, and refresh only what is really needed. Overusing refreshes or large commits leads to poor performance and a bad user experience.