Transactions and Concurrency

Flowable Engine
1

Hi!
We are implementing an fully automated provisioning process where the bpmn part consist of a parallel gateway and several call activities to sub-processes containing the integration logic. We come upon this issue of concurrent transactions and “optimistic locking” in flowable during execution:

org.flowable.engine.common.api.FlowableOptimisticLockingException: ProcessInstance[61128] was updated by another transaction concurrently

I have read the chapter “Transactions and Concurrency” in flowable docs and especially “Why exclusive Jobs?” section, but I am not fully comprehending the idea. How do we post data to several external sources in parallel flows without getting “optimistic locking” or concurrency issue at the parallel gateway join (asynchronous=true)? Exclusive=true doesn’t seem to work either.

Our problem right now in test is that we cannot use parallel gateways for sending data to multiple external systems in parallel without risking “optimistic locking” stepping in, doing the tasks again. This results in external systems recieving duplicate messages.

Is there a way to solve this in the process logic?

2

As a quick fix, we added a timer event right after one of the call activities (see screenshot). If we dont use it, we get optimistic locking every time and the last task will be done again causing duplicate updates sent. Both call activities are configured as exclusive=true.

image

3
  • What is happening in those ‘send to system x’ tasks? A send and wait or only a send? Can there be a race condition there?
  • Exclusive jobs guarantee only one per process instance is executed. Did you make your send tasks exclusive too, besides the parallel join?
4

Hi Joram and thanks for your response!
I went over the parent and backend process called from the call activities and changed all tasks and gateways to exclusive=true. I thought it was enough to only set exclusive=true on the call activities in the parent process. Now I am not recieving optimistic locking issue during tests anymore. Thanks!

Our general idea is to use a generic integration process for the majority of our web service integrations, with fault handling. We are using a service task with camel routes to the backend, and throwing “undefinedError” on all error events that initiates the error boundary event. This triggers a notification the first time and takes you to a user task for retry, ignore or abort. after a given time, it will automatically try again.

image

5

Hi.

I have a somewhat related question so thought I’d avoid another topic.

I’m getting this exception in FlowableRule unit test:
org.flowable.engine.common.api.FlowableOptimisticLockingException: org.flowable.idm.engine.impl.persistence.entity.GroupEntityImpl@4edef76c was updated by another transaction concurrently

I want to setup users / groups to unit test a TaskListener. Snippet below:

    RuntimeService runtimeService = FlowableRule.getRuntimeService();
    IdentityService identityService = FlowableRule.getIdentityService();

    Group group = new GroupEntityImpl();
    group.setName("name");
    group.setId("groupId);
    identityService.saveGroup(group);

Exception on this last line.

What am I doing wrong?

Thanks.

6

So this works:

    Group group = identityService.newGroup(groupId);
    group.setName(groupId);
    group.setId(name);
    identityService.saveGroup(group);

Sorry, wasn’t obvious when I started. :slight_smile: