RE: Concurrency issue due to parallel processing

SurajitSen — Fri, 16 Jul 2021 11:50:41 GMT

Thank you for your suggestion. I shall recheck all the nodes which you have mentioned.

RE: Concurrency issue due to parallel processing

Chris — Wed, 14 Jul 2021 14:46:41 GMT

As you note that only one user can act on one data set at a time, and it appears pessimistic locking is implemented to handle this, I would not expect any amount of concurrent processes using the same interface object, but different data sets, to cause any issues that revert data unless there is a design situation allowing such.

Are locks granted at both the Add Editing User and Update Status node? For instance, if a lock was not granted at the Update Status node, a second user could begin and complete an Edit. After that time if the initial Update process's MER Form node timed out to the Remove Editing User node - if that node is updating the full data set which was queried into a process variable prior to the edit, it would revert any edits made through the other process. Just a thought - as it appears the "Button?" XOR allows the process to close without updating any data / removing locks (unless you are doing so on the form with a!writeToDataStoreEntity().

Additionally, are you able to locate any specific instances which have 'reverted' the data for troubleshooting?