Extending Locks of External Tasks

By
  • Blog
  • >
  • Extending Locks of External Tasks
TOPICS

30 Day Free Trial

Bring together legacy systems, RPA bots, microservices and more with Camunda

Sign Up for Camunda Content

Get the latest on Camunda features, events, top trends, and more.

TRENDING CONTENT

The External tasks concept was introduced in v. 7.4. So far, only two operations existed to deal with external tasks: Fetch & Lock and Complete (read more in our docs).

These operations may be enough in most of the use cases, but can also cause a lot of inconveniences:

  • When an external task represents a long-running operation (like video transcoding, data indexing, etc.)
  • When it’s hard to estimate the time that the worker will need to finish the task

Before v. 7.8, a worker had to choose the lock duration at the very beginning, when fetching the task, and it did not have a margin for error. If the lock duration is not big enough,
so that the worker is not able to complete the task in the given amount of time, the task can be fetched by another worker. As a consequence, two workers will do one and the same job,
which can lead to huge problems like data inconsistency, etc. On the contrary, if the lock duration is too long and the worker can’t complete the task for some reason (system crash or anything),
then another worker is not able to take over the work, unless the timeout has been reached.

To resolve such problems, starting with version 7.8, the new operation Extend Lock was introduced. It allows to sequentially update the lock duration for the external task,
while working on it.

Previously, the process could look like this:

External task scenario before v.7.8

Let’s imagine that we have two servers up and we Fetch & Lock and start a long running process on one of those servers. This long running process could take 8 hours to complete,
so we set the timeout to be 8 hours. Two hours into the process, that server has a problem and is automatically torn down and a new server is brought up
in its place. Previously, Camunda (and the second server) would have continued waiting for another 6 hours before unlocking the task. Only after the timeout has been reached,
the task will be available for Fetch & lock again from another server.

Now, with the new Extend Lock operation, our scenario could look like this:

External task scenario in v.7.8

Every 25 minutes, the first server can report that it is still working on the task and will need at least 30 minutes more. In case it has neither reported “complete” nor extended the lock after another
30 minutes, the task will be unlocked by Camunda and can be fetched for execution by another server.

Also in this pattern, the worker does not need to estimate lock duration at the very beginning. It can just use some “standard” initial value and then extend the lock as much as necessary.

How to use it

In the Java API, the feature can be accessed through the ExternalTaskService:

    ExternalTaskService externalTaskService = processEngine.getExternalTaskService();
    externalTaskService.extendLock("exampleExternalTaskId", "exampleWorkerId", 60000);

In this example, the lock duration is extended by 60000 ms = 1 min.

The REST API call would look like:

POST /external-task/exampleExternalTaskId/extendLock

    {
        "workerId": "exampleWorkerId",
        "newDuration": 60000
    }

For more details, please see the documentation about the
Java API and the
REST API.

Try All Features of Camunda

Related Content

We're streamlining Camunda product APIs, working towards a single REST API for many components, simplifying the learning curve and making installation easier.
Learn about our approach to migration from Camunda 7 to Camunda 8, and how we can help you achieve it as quickly and effectively as possible.
We've been working hard to reduce the job activation latency in Zeebe. Read on to take a peek under the hood at how we went about it and then verified success.