Pessimistic Locking

Category: Samples
Subcategory: Examples

Overview

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.)

Documentation

Description

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. 

The basic principle is to use the GUID of the object as the key for the lock record entity and apply a uniqueness constraint on the GUID.  This prevents two locks being created for the same object, even if a second transaction commences before the first is committed. 

Note that where two locks are requested simultaneously (before the first has committed), the second transaction will be blocked until the first has committed, so there could be a visible delay if you have long running microflows. 

Typical usage scenario

It is important to prevent two users from editing the same entity instance at the same time.  E.g. Sales Order, Employee, etc.

You want to avoid users losing work.

Features and limitations

The lock expiration period is governed by a constant.  If a lock has expired another user can override it.  A before-commit microflow is used to check that the user still has the lock at the time that they commit a transaction.  The expiration period for the lock is reset each time the lock is confirmed, so that the expiration is a measure of inactivity rather than of how long the user has been working with a particular piece of information.  Details are annotated within the model. 

Dependencies [optional]

 

Installation [optional]

The project is provided to demonstrate a way of achieving pessimistic locking.  To install, export the “ObjectLocking” module and import it into your project.  You will need to connect it to the objects you want to lock following the pattern in the example project. 

It is important that you take full responsibility for testing that it meets your requirements. 

 

Configuration [optional]

A constant is provided to set the lock timeout period.  You may want to change various aspects of the locking behaviour to meet your specific business requirements. 

 

Known bugs [optional]

 

Frequently Asked Questions [optional]

  • Q:
  • A:

Releases

Version: 1.0.0
Framework Version: 7.15.1
Release Notes: First public release