How add locking in the database?

0
Hi,   I have a scenario. I will explain through example. Entity: Customer (Atributes: {CustomerID ,Customer Name, Age, Address}) There is a button on page to create object for this customer entity but this form can be accessed by different users of different user roles at the same time. Now CustomerID is unique but we can not apply this to the domain model because we have to create versions of customers in the application flow with the same ID. But customerID uniqueness is only checked at the creation of a new customer, so we applied validation in microflow for saving Customer object.   It works totally fine when it is creation of object one after another but if two different users open form at same time and try to create object with same customerID then it fails to validate uniqueness. How can I solve this?   Thanks and Regards, Harshraj Singh
asked
2 answers
0

Hello Harshraj Singh,

 

Is it a possibility to create an entity next to your customer entity that is called something like UniqueIdentifier which has a 1-* relation ship to Customer, in this way you can put a the uniqueness validation on the string attribute of UniqueIdentifier and does it need to be unique. And you have to make the flexibility to create different version of the customer. 

 

Hope this helps,

 

Good luck!

answered
0

I'm a bit unclear why this uniqueness can't be solved by adding a uniqueness constraint on the entity (attribute), so on the database level. So I can't advice on that.

However there are different ways of solving this concurrency problem:

- Microflow properties: set concurrent execution disallow to true, this will prevent users from executing the microflow concurrently (not very user friendly)

- Create a pessimistic locking mechanism like this module provides: https://marketplace.mendix.com/link/component/109405

- Create a non-persistent version first and when completing the form write to the persistent entity

But I think you should revisit how you want to use and generate the CustomerID, as this is typically something the database can handle well

answered