As per the Salesforce documentation here...
Each execution of a batch Apex job is considered a discrete transaction. For example, a batch Apex job that contains 1,000 records and is executed without the optional scope parameter is considered five transactions of 200 records each.
You can modify this behaviour by applying the interface Database.Statefull to your Apex class.
global class SummarizeAccountTotal implements
Database.Batchable<sObject>, Database.Stateful{
In this case the following then applies.
If you specify Database.Stateful in the class definition, you can maintain state across these transactions. When using Database.Stateful, only instance member variables retain their values between transactions. Static member variables don’t and are reset between transactions. Maintaining state is useful for counting or summarizing records as they're processed.
Note that the GMirror.X and GMirror.Y variables need to be 'instance' variables of your class to be stored, otherwise they will be reset. To work around this you could change them to instance variables and store an instance of GMirror in your Apex Class.
public MyJob implements Database.Batchable<sObject>, Database.Stateful
{
private GMirror gm = new GMirror();
public void execute(Database.BatchableContext BC, List<sObject> scope)
{
// Here gm.X and gm.Y will be maintain throughout the job
}
}
Or store X and Y as instance variables in your batch and at the top of your execute method assign them.
public MyJob implements Database.Batchable<sObject>, Database.Stateful
{
private Integer gmX;
private Integer gmY;
public void execute(Database.BatchableContext BC, List<sObject> scope)
{
// Here gmX and gmY will be maintain throughout the job
GMirror.X = gmX;
GMirror.Y = gmY;
}
}
The later option does not require any change to the GMirror class and also does not give rise to potential side effects of persisting other instance variables of this class. For more information see the larger example and explaination in the Salesforce docs here.
More Advanced Thought: As a more advanced option you might want to consider a factory pattern to maintain a static instance of GMirror, but create a GMirror.State inner class that can be passed (perhaps optionally) to the GMirror factory method.