Collectively referred to as asynchronous code batchable, queueable, and the @future methods contract a tradeoff with the Salesforce1 platform. In exchange for running the code asynchronously, meaning we have no control over when it's actually executed, the platform relaxes certain governor limitations. For instance, during normal, synchronous Apex execution, you are limited to modifying 10,000 records per DML call. Attempting to access more than 10,000 records throws a SOQL error. However, during the execution of a batchable class, those governor limits are reset every time the execute method is called.

Conceptually, asynchronous code executes in two steps. First, the code is queued. As system resources allow, the system pulls jobs off the queue and executes them. As usual, the devil is in the details. Batchable, Queueable, and the @future annotation all have various tradeoffs that distinguish them from each other. Knowing when to use which one is crucial. As we work through each of the options, we'll talk about appropriate use cases for each.

For batchable jobs, there is an intermediary step between queuing and execution: chunking. When you execute your batch job, the system runs the initial query and chunks up the results, enqueueing N number of jobs—one job for every X number of results. The X factor is the batch execution context, or the number of records that each batch will process. As the developer, you can specify what the branch execution context is when you start the job. If left unspecified, it defaults to 200 records per chunk.

The Database.batchable interface, provided by the platform is straightforward. Simply extended your class with Database.Batchable, like this:

public with sharing class myBatchable extends Database.batchable

Once you've extended Database.batchable, you're required to implement the three method signatures the interface requires. The first of the three required methods is the Start method, which the platform calls at the beginning of batch's overall execution:

global Database.QueryLocator start(Database.BatchableContext BC) {
  return Database.getQueryLocator([
SELECT IDId, FirstName, LastName, BillingAddress
    FROM Account
    WHERE Active = true AND BillingState = 'Tx'
    ORDER BY Id descDESC
  ]);
}

This first method gathers the records or objects that the execute method will act on and, in conjunction with the execution context, determines the number of chunks that will be executed. The start method provides two possible return values, either a Database.queryLocator object or an iterable object, such as a List. The preceding example uses queryLocator. Regardless of the type returned, it must accept a single parameter of the Database.BatchableContext type. When the execute method is called, it returns an ID, which you can use to query the AsyncApexJob object. The AsyncApexJob object gives you insight into the status of a batch job:

global void execute(Database.BatchableContext BC, List<Account> scope) {
  for (Account a : scope) {
    //Complex operations against individual 
//Account records here
  }
  update scope;
}

The Database.batchableContext BC variable is essentially dependency injected by the system. However, our second method, the execute method, must reference it to fulfill the batchable interface. The execute method is run once per chunk. It accepts not only Database.batchableContext, but also a chunk of records; a list of whatever object the start() method returns. In the preceding example code, I've called that chunk scope, and in this case, it's a list of the Account objects. Because the execute method is called once per chunk, scope is essentially a local iteration variable. Thankfully, the platform dependency injects a chunk into every execute call; meaning we're not responsible for running the execute() calls ourselves.

The general pattern for a batchable class execute method is to iterate over the given scope using a for. In general, this for loop is where you implement your custom business logic either by placing the logic there in the execute method, or better yet, calling a dedicated class method much like we talked about with triggers. While you modify individual records inside the for loop, like a trigger, you must keep DML outside of your loop! Loop over your scope records, modify them, and then insert/update/delete, and so on, all of them at once just after the loop ends. If you need to use the loop to determine what kind of DML ultimately happens to the records, do so with multiple lists. For instance, if you're iterating over a scope of accounts and determining which of them to delete, create an additional list and use that to delete those records in bulk as shown here:

global void execute(Database.BatchableContext BC, List<Account> scope) {
  List<Account> toDelete = new List<Account>();
  List<Account> toUpdate = new List<Account>();

  for (Account a : scope) {
    if(a.bad_account__c){
      toDelete.add(a);
    } else {
      toUpdate.add(a);
    }
  }
  update toUpdate;
  delete toDelete;
}

In this example, we're not actually updating the scope directly, but rather splitting the records into two lists. One to delete, one to update, and only then calling the appropriate DML after the loop is finished.

Of all the methods of the batchableBatchable class, the execute method is conceptually the most straightforward. However, it's often the most difficult to perfect. It pays to keep in mind the governor limits affecting batchable class execution. While asynchronous Apex, such as jobs conforming to the batchable interface, relax some governor limits, your execute method is still limited to 10k rows per DML call. If, for instance, you utilize the increased memory you have available to access to more than 10k, you'll hit governor limits even if you use the bulk pattern discussed earlier. On the other hand, if you're executing SOQL queries within your execute method, but outside your for loop, you're bound by the standard governor limits, they just reset every time the execute method is invoked.

The third method in the batchable interface is the finish() method. The finish method is run after the start() method has queued all of the chunks and those chunks have been executed. The general idea is that after your batch job is functionally completed, the finish method can send e-mail notifications to users or handle execution exceptions. In general, such cleanup tasks should rarely rely on specific data, but can reliably rely on the jobs execution to be complete. For instance, if you use a batch job to look at all of your opportunity records in order to sum the value of all records meeting a certain criteria, your finish() method would be responsible for persisting the summary record.

Knowing what to use the finish method for can be one the most confusing aspects of the batchableBatchable Apex classes. It is safe to use the finish() method for things that are guaranteed to have run. However, it is not safe to depend upon any data generated by the batch. This is because the data generated by an execute method may not always exist. Exceptions within the execute() method force a roll back of any DML thus, if an exception occurs, the data you expect may not actually be there when your finish method runs. On the other hand, knowing when to use a batch class is fairly straightforward. Use batch class when you need to carry out the same logic against a large number of records; specifically, more than 10,000 records. Using a Database.Batchable class allows you to access or modify up to 50 million records per queryLocator. At a maximum DML chunk size of 10,000, this means your batchable class will queue 5000 chunks.

Global Class CustomBatchable Implements 
Database.Batchable<sObject>, 
Database.Stateful, // This implements the Stateful interface
Database.AllowsCallouts { // This enables Callouts
}

global double totalSum =0;

Global Class CustomBatchable implements Database.Batchable<sObject>, Database.Stateful, Database.AllowsCallouts {
  //failedToUpdate persists throughout the entire job.
  Private Set<Account> failedToUpdate = new Set<Account>();
  //Because it's marked Static, updatedSuccessfully
  // resets every time the execute method runs 
  Private Static Set<Id> updatedSuccessfully = new Set<Id>(); 
  String query;

  global CustomBatchable() {
    //Optional constructor, useful for setting query 
    //variables like Dates etc. Setting the query in the 
    // constructor allows you to use dynamic SOQL as well
    this.query = 'SELECT IDId, Name, BillingStreet, BillingState 
    FROM Account ORDER BY Id DESC';
  }

  global Database.QueryLocator start(Database.BatchableContext BC) {
    return Database.getQueryLocator(query);
  }

  global void execute(Database.BatchableContext BC, List<Account> scope) {
    for (Account a : scope) {
      if (a.BillingState == 'Tx' || a.Name.contains('awesome')) {
        a.Active__c = 'true';
      }
    }
    Database.SaveResult[] results = Database.Update(scope, false);
      
    for (Database.SaveResult sr : results) {
      if (sr.isSuccess()) {
        updatedSuccessfully.add(sr.getId());
      }
    }

    for (Account a : scope) {
      if (!updatedSuccessfully.contains(a.Id)) {
        failedToUpdate.add(a);
      }
    }
  }

  global void finish(Database.BatchableContext BC) {
    if (failedToUpdate.size() > 0) {
      //Email admin about failed updates
      //Or process them individually, attempting to 
      //auto-correct DML issues.
    }
    //Once done processing the failed records:
    List<Account> insertNow = new List<Account>();
    insertNow.addAll(failedToUpdate);
    insert insertNow;
  }
}

Id batchJobId = Database.executeBatch(new CustomBatchable(), 200);