0

Why Queueable came into the picture when we already had Batch Apex available to Us. I know Queueable is better than future in context of accepting non-primitive data types and for job monitoring and chaining of jobs, but we still can do that with Batch Apex.

Noob_NoVoice
  • 2,709
  • 16
  • 66
  • 88

1 Answers1

2

Queueables consume daily async executions from your limits somewhat like Batches do, but:

  1. You can only have 5 batches executing at the same time
  2. You can only have a further 100 batches queued for execution.

On the other hand, there are no limits on the number of queueables that can be added (and thus pending execution), other than the 50 (or in async context 1) additions per transaction. My point is that many transactions can queue very many queueables.

Further, a batch consumes a minimum of 2 (and usually 3) async executions because start, execute and finish each consume one async execution, whereas a queueable only consumes a single execution (unless it then chains to a further execution, which is entirely under the control of the developer unlike for a batch).

NB: if you determine that you don't want the queueable to perform further processing you can just stop by simply not chaining, but you cannot prevent the later chunks being sent to a batch without explicitly aborting it (which you may not be able to do due to missing user permissions).

Queueables now also have Transaction Finalizers to allow handling of errors, even if these are caused by broken governor limits.

All in all, queueables are far more flexible than batches and can in principle be used to do anything you would typically do with a batch without the execution and queuing limitations.

One positive benefit of batches: the code in a given start method is guaranteed to be executed in a single threaded manner on your org (no two batches will be executing start in parallel). This gives you a place to perform certain checks knowing you cannot have a race condition around it.

Another benefit of batches: these are good at handling large volumes of records (up to 50,000,000) via a single SOQL Query Locator. To do similar in a queueable means messing around slicing up your data domain in some "manual" (and probably fragile) manner - i.e. you have to write this for yourself.

Take a look at these previous Q&As:

Phil W
  • 36,007
  • 4
  • 45
  • 91
  • Interesting. Definitely learned a thing or two from your answer. However, the way you wrote it makes batches look bad but in reality they are the preferred way since they ran much faster than chained queuables. In fact, Salesforce made queuables to replace future methods and not batches. There are some cases where queues are preferred but that's usually not the case.

    Also, "there are no limits on the number of queueables that can be added" isn't correct. Error: Too many queueable jobs added to the queue: 51

     – Harout Tatarian Oct 04 '21 at 16:47
  • @HaroutTatarian I have clarified what I mean with "no limits" - I didn't mean in a given transaction, but over-all in the org. As to batches, there are many downsides. I did add a second benefit when you consider large data volumes. As to performance, because you can have only 5 batches running concurrently you can find that your batch may spend a long time queued before it gets executed, if there are too many batches in your org, which has a real-time negative impact on (perceived) performance. – Phil W Oct 04 '21 at 16:56
  • Thanks. I always thought the "Too many queueable jobs added to the queue: 51" was an org wide limit and not per transaction. That's super helpful. – Harout Tatarian Oct 04 '21 at 16:58