It seems that Mendix is Optimistic concurrency control. Here is my problem: I want to prompt a user while he is working, that somebody else changed his record and give him the opportunity to refresh the current record without saving. The only way I see me doing this is using a microflow that checks the changedate from my record and compare it to the one in the Database from a microflow timer. The problem here is, it seems like the "current" record is exactly the same as the one from the DB. Here is my form with the timer set to 10 seconds: This is the important part of my Microflow: * I'm only logging for user1 so that the console does not get spammed. Here is a sample project and video to explain the outcome: File Video What happens here is, the microflow logs for user1 [on the left] if his in-memory record differs from the one in the database. So when user2 [on the right] changes the record, user1's [on left] microflow logs the DB values instead of the values that the form was initialized with. I then added a refresh in client even if the values seem not to change. So, question is, how do I keep a handle on my old data to compare it to what is actually in the DB so that I can resolve potential conflicts?
We have implemented optimistic locking as described below.
Every table has an attribute called UpdateCounter (integer).
In the before commit trigger the updatecounter of the record to be committed (ObjectCurrent) is checked against the updatecounter of the same existing record on the database (retrieve xpath [id = $prefRuleObjectCurrent]).
When the updatecounter has value 0 the commit concerns a new record and locking is not applicable.
If no record is found on the database, the record is deleted by another user.
If a record is found and the value of the updatecounter is higher then the ObjectCurrent.updatecounter, the record is changed by another user. You can refresh the data of the CurrentObject with the new values (CWE + refresh) and return false for the BeforeCommit event.
If a record is found and the value of the updatecounter is equal to the ObjectCurrent.updatecounter, the record is not changed by another user and can be committed and the updatecounter must be raised by one.
Note that you can use aggressive locking as well, its provided in the communtiy commons package, and allows you to control locking manually.
(I did not look into the video yet so a more extensive answer might follow ;-))