Manage asynchronous operations in Jitterbit Studio

Introduction

When operations run asynchronously, they execute in parallel without returning control to the calling function. This can cause race conditions when multiple operations read from or write to the same resource, and can overwhelm an agent if too many operations run simultaneously. This page covers how to avoid both problems.

Limit simultaneous operations

When using the RunOperation function in its asynchronous mode, operations execute without returning control to the calling function. Use of asynchronous operations can lead to race conditions.

For example, if Operation A updates a database table and is chained to Operation B, which reads that same table (both are synchronous), no race conditions are encountered. But if Operation A is called asynchronously followed immediately by Operation B, then B may execute before A is finished.

In addition, the number of simultaneous asynchronous calls must be managed, as the number of simultaneous operations running on an agent is capped (see the private agent configuration file's [OperationEngine] section or Cloud agent groups).

How to avoid these problems

Race conditions

When multiple operations read from or write to the same resource, run them synchronously by omitting the async flag from RunOperation. Synchronous calls return control only after the operation completes, so each operation in the chain starts only when the previous one has finished.

Use the asynchronous flag only when the dispatched operations are truly independent and do not share state (for example, sending a batch of independent API calls where the results do not need to be collected in a specific order).

For a real-world example of safe async dispatch, see Receive Slack events in a Studio operation.

Operation cap

The maximum number of simultaneous operations is set in the agent configuration:

• Private agents: Increase the MaxOperations value in the [OperationEngine] section of the private agent configuration file.
• Cloud agent groups: The limit is configured per agent group in the Management Console.

If the cap is reached, the RunOperation call queues until a slot becomes available. Operations are not dropped, but latency increases when the cap is consistently hit. Raising the cap is a short-term fix; the longer-term solution is to reduce unnecessary parallelism.

For guidance on recovering from operation failures in high-throughput scenarios, see Retry a failed operation.