Best/easiest way of locking object

Hi all, Scenario: If one user is currently editing an object, another user should not be able to edit the same object, until the first user finished the editing process.   What I found out of my research: A Module “Object locking” exists in the Mendix App Store, however it is not compatible with Mendix version 7 or not recommended to use it with version 7 This feature was requested from a lot of Mendix developers/users, however until now there is no common solution – is that correct? Some smart people figured out their own locking-solution, mainly done with microflows This post is the latest regarding to Object locking:   My approach: If I made my research correctly and understood the community than there is currently no module or out of the box solution for object locking (for Mendix version 7) This means I have to develop my own solution.  I will create an microflow which is triggered by the edit-button of an object. This microflow checks if the status of the object is locked, and if not, than sets the object to locked, otherwise the object will be opened in a read-only view After the user closes/exists the edit-page, the object will set to “unlocked” again The status if an object is locked or unlocked will be stored in an separate entity   Question: Is there a logical mistake in my approach? Is there a better/smarter way to achieve my scenario?    Best regards, Ömer    
4 answers

Hello Omer,

I think you can simplify your approach a bit by just having a separate object for locks, rather than an object which tracks locked-unlocked status. You can potentially minimise the performance and memory overhead this way.

As far as gaps go, think about what you will do if a user doesn’t close a page (i.e. if a user locked an object and then they just close the browser)

Hope this helps




We had kind of the same situation. Our domain model looked like this: We have a person entity, which is associated 1-1 with account entity. Account entity is a specialization of System.User.


We've created an association between the object to be locked and the person. At the moment a user opens the object, the association is set with the person. That way we also know which account locked which object. At the moment the person leaves the object page, the association is set empty. Every time a person opens a object, first is checked if the association is filled or not. If true, the user opens the object in read only mode. If false, the association is set and the user can edit the object. It's important that wheter you create or delete a lock, you immediately commit to the database.


As far as Dragos says above: you still keep having the problem of users who don't close the page/object correctly, for example by closing the browser window. That way your object will kept locked. A possible solution is quite simple: create a scheduled event who cleans up the locks. You could run it for example like every 10 mins, worst case scenario a user has to wait 10 mins until he can edit the object. Your SE can look like this:


- Retrieve a list of all locked objects, by retrieving a list of objects with the new association. 

- Retrieve a list of all locked objects with a session, by  retrieving a list of objects by the new association all the way to session in the system module  (we did it by in this example Object_Person/Person/Person_Account/Account/Session_User/Session)

- Subtract the list of all locked object by the list of all locked objects with a session. That way you get a list with all object locked by a user who has no session. Those objects are the one you want to unlock.

- Loop over these objects to empty the lock association.


I'm not saying this is the best solution, but it's quite clean and easy to build with standard Mendix functionality. It may help you out or at least give you some ideas.


This module still works perfectly fine if you upgrade it from 5 to 6 to 7 :-) Just did that myself recently for a project and very happy with how it works:



Making a locking mechanism perfect is quite a challenge.

  1. The Mendix Locking Module works only on one cloud node and is not suitable for load balancing.
  2. A lock in a database is not atomic, that means that it is possible to lock a record by two users.
  3. Implement a mechanism for a manager to unlock if the locking fails.


Consider a solution without lock, just show the current user, or check the current user before saving.