Unable to stop the Race conditions in a process model

Question

When I select the items in the grid and click on the button in the background the process model should trigger, and it must complete successfully, But when I click the button instantly twice or thrice immediately another process model is triggering the items which have selected becomes duplicate in next section. So, Here race condition occurs. Actually, we tried to restrict that button not to click it a second time by the user. The problem is before writing to the DB by the first process model in the fraction of seconds processes model also. In the interface, we are passing the selected items through the start process and try to capture the output. But nothing works. Let me know is there any way to stop the race condition either in an interfcae or process model

Chris · Answer

To start us off here, why is a process model required to write data to the DB on a button click while the interface is still active? If this is a requirement, note utilizing a!writeToDataStoreEntity() on the button click instead is much lighter and much easier to control. 
 Additionally, if you set a flag on the button click, users should only be able to click once - potentially reset the flag to false if any data is modified that might need to be persisted to the DB? Otherwise if you can post more details about your configuration and use case, that would assist here. 
 a!localVariables(
 local!buttonClicked: false,
 
 {
 a!buttonArrayLayout(
 buttons: {
 a!buttonWidget(
 label: "Write Data",
 value: true,
 disabled: local!buttonClicked,
 saveInto: {
 local!buttonClicked,
 a!writeToDataStoreEntity(
 dataStoreEntity: cons!COE_DS_TESTING,
 valueToStore: 'type!{urn:com:gdit:types}COE_TESTING'(data: "test")
 )
 }
 )
 }
 )
 }
)

Dave Lewis · Answer

If you need an entire process to run in the background, one thing you might want to consider is actually making the button a submit button. Submit the form, move on in the process, call a synchronous sub-process (so it has to finish before you can move on) and activity chain the whole thing in a massive loop back to the same form you were in. If you can configure it well enough, you might be able to dump the user right back into the same form in such a way they won't even notice that they left and came back. (It really, really helps if the form is so short that there's no scrolling.) 
 Another thing you could do is simply add a Task Form to your subprocess as a confirmation screen. You load that form in a branch near the beginning. Use an AND gate at the beginning and at the end, so the DB processing AND the form both have to be done before it terminates. The user has to reach over and click the "OK" button to close the form, which does nothing but hide the main form from the user while you complete the write. 
 If you don't need to do that much processing with other script tasks and such, it is best to avoid the subprocess and just process in a rule you call that calls the a!writeToDataStoreEntity() as suggested below. If it's simple enough, that is the best approach if you include the toggle to make sure the button can't be pressed multiple times. Without that, it will seem just like the race condition.