Safeguarding against optimistic locking errors across instances

Hello!

We’re using Camunda 7 embedded into a Spring application with multiple instances, and with a custom REST interface that allows frontend applications to interact with our BPM processes. Recently we’ve run into an problem where the frontend would duplicate calls to complete a user task, which then caused Camunda to raise optimistic locking errors.

I realize the errors are expected behaviour and that they are not fatal to the process instance, but still we’d like to introduce some safeguards. Is it possible to tell Camunda to, say, lock a process instance when it’s picked up by one of our service instances for processing, so that it can’t be picked up again until it reaches a wait state?

Hello @mzbrozek
One way you can reduce the chances of this behaviour is checking the “async after” box on this user task. This way, camunda will commit earlier to database the task completion, without waiting for the next parts of the processo to complete too. Without this option, you camunda will try to execute the next delegates and things like that in the same java thread and database transaction, so it may take longer to commit the end of the task, making your next request still see the task uncompleted on the list, thus trying to complete it again.

An improvement would be to work with task claim, but it can get more complex and i suggest you read this another thread if the first solution doesnt fit: Block claimed tasks - #14 by MarioH

4 Likes

Sounds promising, we’ll look into it. Thank you!

hey @mzbrozek did it solve your problem?

We decided to go with a different approach and filter incoming requests based on a cache, so Camunda doesn’t even interact with duplicate requests.