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: https://appstore.home.mendix.com/link/app/468/
Making a locking mechanism perfect is quite a challenge.
Consider a solution without lock, just show the current user, or check the current user before saving.