Does indexing a table make the user wait longer when doing a commit?

When doing a commit on an object of a very large table will Mendix either: - commit the object, return control to the microflow and then update the index or - commit the object, update the index and then return control to the microflow At this is stated: 2.4 Performance Considerations Changing and deleting objects of an entity with indexes takes longer, because the index needs to be updated in addition to the actual data. Therefore, for attributes that are rarely used as criteria in a search or query, only create an index if the increase in retrieval performance justifies the decrease in update performance. which kind of implicates that the index gets updated before the control is returned, but still it can mean that it takes longer for the entire data, hopefully without having to make the user wait on updating the index.
2 answers

Hi Tim,

maintaining the index(es) should be taken care of by the database engine, not Mendix. In other words, the indexes are updated as soon as Mendix issues the actual “Commit” command to the database.

To my knowledge, this happens at the end of each microflow transaction (or when explicitly invoking certain Java actions in the Community Commons module), but always before returning the control to the microflow.

Side note: The community commons module contains a Java action called “commitInSeparateDatabaseTransaction” which might be helpful, but I I am not sure about the implications of using it :)


I am not sure about your question, but based on the docs and based on what I learned once, if you use indices on tables, it could make search process faster but write process slower and should also increase the size of the tables in comparences to have no indices. But I would think it is also related to the used database of how this is handled. 

This sounds for my like a awesome test to compare the behavior with the two different scenarios and the results. I would be curious about the results :)