0

SimpleQueueable.cls:

public with sharing class SimpleQueueable implements System.Queueable{
    public void execute(System.QueueableContext ctxt){
        //query the record inserted in calling transaction
        //make some changes on the record and update the record.
    }
}

Sample code of calling transaction:

SimpleQueueable job = new SimpleQueueable();
System.enqueueJob(job);
Long start = System.now().getTime();
while(System.now().getTime() - start < 6000 ){
}
// Decimal x = 6/0; If I uncomment this line queueable is not running.

Behavior of Queueable job :

  1. Only run if calling transaction completes successfully.
  2. Only run after the completion of calling transaction and should not run in parallel with calling transaction.
  3. Query the record that is inserted in the calling transaction and do some updates and update the record.

About calling transaction:

Calling transaction starts with custom code and ends with managed package code. So, I don't have a way to know when the calling transaction ends.

What I have noticed:

  1. If the calling transaction is failing then queueuable is not executed.
  2. Queueable job is executed after the calling transaction is completed.

Can someone confirm this or my findings wrong?

3
  1. If the calling transaction is failing then queueuable is not executed.
  2. Queueable job is executed after the calling transaction is completed.

This is correct. Whenever you invoke Asynchronous Apex (whether Queueable, Batch, Scheduled, or Future), your request is persisted to the queue when your transaction commits successfully.

If an unhandled exception is thrown (or a rollback operation is otherwise performed), all enqueued asynchronous Apex will be rolled back along with regular sObject DML.

| improve this answer | |
2

100% - like all async processing this is handled by creating a record in the database which is consumed by the Salesforce runtime at a later point based on processing availability and schedule. For the async processing to happen, therefore, the transaction must have finished since this is when the database transaction itself is finalized.

| improve this answer | |
1

As a more generic answer: everything that occurs "at the end of a transaction" will not happen if you fail to reach the natural end of the transaction successfully, either by governor limits, an unhandled exception, or an addError/validation rule that causes the records to roll back. This includes scheduling jobs, sending emails, running Queueable and Batchable jobs, triggering Outbound Messaging (Workflow), and some Platform Events (those configured to fire on successful transactions only). Also, you can achieve similar effects with SavePoint/rollback, such as:

SavePoint sp = Database.setSavePoint();
MyUtil.sendSomeEmails();
MyUtil.doSomeBatchableStuff();
MyUtil.doQueueableStuffToo();
// None of the above actually "happened" as far as the database is concerned!
Database.rollback(sp);

So, because of this behavior, you can guarantee that the Batchable/Queueable/Schedulable/Emails cannot occur before the transaction ends, with the exception of the "immediate send" Platform Events.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.