The Winter ’15 platform release brought us the new Queueable Apex interface. It is a cool way to execute asynchronous process working much like what we used to use: @future. But it brings some new performances which are really cool. This article is going to compare the @future and Queueable Interface.
A future method runs asynchronously. And its governor limits are higher:
|Description||Synchronous Limit||Asynchronous Limit|
|Total number of SOQL queries||100||200|
|Total heap size||6MB||12MB|
|Maximum CPU time||10,000 milliseconds||60,000 milliseconds|
When to use it:
- Long-running operations (callouts to external web service)
- Separating mixed DML operations (i.e. inserting a user with a non-role must be done in a separate thread from DML operations on other sObjects)
How to define it:
- future anotation
- Must be static and return void
- Specify (callout=true) to allow callouts
- Parameters passed in can be only of Primitive type
- Cannot chain @future method
- Cannot get the job ID
This interface enables you to add jobs to the queue and monitor them which is an enhanced way of running your asynchronous Apex code compared to using future methods.
Like @future, a benefit of using the Queueable interface is that some governor limits are higher than synchronous Apex (see the table above).
When to use it comparing with @future:
- Chaining jobs
- Asynchronous monitoring (it gets job ID)
- Using non-primitive types
How to define it:
Much like what we did on using batchable interface
- Implement the Queueable interface
- Define execute() method
- Chain this job to next job by submitting the next job
- Implement the Database.AllowsCallouts interface to allow callouts
- When chaining jobs, you can add only one job from an executing job with System.enqueueJob.
- Cannot have more than 1 job in the chain that does callouts.