The object locking feature in Community Commons was removed for Mendix Version 7 because it did not support horizontal scalability.
This project provides a simple solution for Pessimistic* Locking that stores record locks in the database and so will work for applications that have the potential of horizontal scalability.
It uses basic Mendix features and requires no custom java actions (except for a couple of basic actions from the Community Commons module).
The logic contained in this project has been used in a live project and has been reviewed by Mendix for any obvious flaws. However, it is offered without warranty so, if you use it, it is your responsibility to:
1. Review and adapt the logic as necessary to ensure it meets your business requirement (notably what happens if the record is already locked and what happens when the lock has been lost when a commit occurs)
2. Test your implementation to ensure it works as you expect
All feedback is very welcome.
* “Pessimistic” locking requires that the user has an explicit lock before they edit an object. Only one user can obtain a lock on a given object at a time. (“Optimistic” locking by comparison allows a user to edit any object but runs a check before the object is committed to see whether the object has been changed by another user since it was read – and throws an error if it has.)
Solutions5 stars, based on 1 votes
5/5starsDue to the move from on-premise to cloud v4, we lost the ability to lock entities when being edited with the upgrade to Mendix 7. Since this was a critical application requirement, we had to find another way to implement a solution. Pessimistic Locking solved it for us. Very glad you've made it available!
Our use case: User 1 wants to edit object A. User 2 already has it open and has unsaved edits. User 1 must not be able to open it as this would result in action based on outdated information