Can anyone advice optimistic locking solutions?

Hello experts.  I am trying to create an optimistic locking solution. I created a new attribute named by ‘ver’ with integer data type. and a new entity event handler, before committing object, compare ver, if ver is same, commit change, otherwise cancel commitment, and show a message to user. but it doesn’t work, I found if i don’t change the value of ‘ver’ from browser, it isn’t be passed to Microflow.  when I debug the microflow, I found, the  value of ‘ver’ is always refreshed from database. Any idea or advice about it? Could you please give me some solution/hint to create optimistic locking? thanks.
1 answers

You cannot implement optimistic locking this way on the server. Take a look at the following picture:

Two users call the microflow at roughly the same time. The ‘ver’ value in the database is 1, the ‘ver’ value of the objects is 1 as well. The first execution retrieves the object from the database, sees that the versions match and commits The version is now 2. The second execution, however, also retrieves the object from the database, sees that the versions match and commits. However, it is this scenario that should be prevented!


The timing window in which this can happen is very small, but it does exist. If you really need to lock, you either need to do it in the database, or you need to implement locking in the microflows, so that the saving can only be executed sequentially. Furthermore, you need to use the Java action EndTransaction, or even then it’s possible to hit a timing window where the information is not yet in the database before the second execution starts! Older versions of CommunityCommons have code to implement locking, but note that this locking does not work once you start horizontally scaling your application.