I’ll take a shot and tell you that the simple answer is to put proper exception handling in the activity that is sending the message to the execution listener. In effect, first process in gets to start it and the second one simply fails gracefully.
I won’t claim deep experience in this area, but my experience does teach me that any time you interact with something outside the immediate class, activity, process (i.e. sending a message, making a REST call, using a Call Activity), that you should implement an exception handler to gracefully deal with any issues.
In my case, a boundary event of the error type suffices to catch errors. In the Event definition, the “errorCode” value of the event can be set to “java.lang.Exception” and it will catch everything. You can them branch out of the boundary event to something that gracefully handles the error or simply exits.
Here’s an example of the XML that defines the error code itself, which is then universally available to all activities that can use it:
<bpmn2:error id="Error_1" errorCode="java.lang.Exception" name="javaGroovyException"/>
Here’s the code from within the boundary event itself where you can see how it links back to the error definition above:
<bpmn2:errorEventDefinition id="_ErrorEventDefinition_3" camunda:errorCodeVariable="gcsBpoMessageRouterErrorVariable" camunda:errorMessageVariable="gcsBpoMessageRouterErrorMessageVariable" errorRef="Error_1"/>
When this occurs, I have a script that evaluates the situation and other activities that then decide whether to continue or exit. Also note that the “errorCode” value can be any class you want. The one above just catches everything. You can also have multiple boundary events on the same activity.
There’s probably something in the Java API that will allow you set/query for these locks if that’s the way you want to go, but I don’t know what that might be. It’s just my guess because that API is exhaustive.
Michael