Timer jobs are a great feature of SharePoint to use when you need to perform background execution at regular or specific times or when you need to execute code on all or selected servers in the farm.
The Variations feature uses specific SharePoint timer jobs to perform tasks such as creating and propagating sites and pages. The Variation Timer jobs are bound to each web application which contain (or contained in the past) a site collection which has the publishing feature enabled.
You can change the Schedule for each job on the Job Definitions page on the Central Administration Web site. The following timer jobs are used to with Variations:
The different Variation Timer Jobs
Variations Create Hierarchies Job Definition
This timer job is responsible to create the variation hierarchy of unspawned labels by creating peers in the new label of sites and pages in the source variation label. By default, this timer job runs once a day.
Variations Create Page Job Definition
This timer job creates peer pages on the target variation sites whenever a user explicitly requests the creation of a variant of a page using the UI (Ribbon or Site Manager) – e.g. if the Automatic Creation option has been disabled and a user decides that a page needs to have a page variant in a different label. By default, this timer job runs hourly.
Variations Create Site Job Definition
This timer job creates peer sites when the Automatic Creation option has been disabled and a user manually creates a new variation site using Site Manager. By default, this timer job runs every 5 minutes.
Variations Propagate Page Job Definition
Creates and updates peer pages in target variation label after a page in the source variation label has been approved or after the update has been manually requested by a user through the Ribbon. By default, this timer job runs hourly.
Variations Propagate Site Job Definition
Creates peer sites when the Automatic Creation option is enabled. By default, this timer job runs every 5 minutes.
Communication between worker process and Timer Jobs
Creating variation hierarchies, spawning sites and pages manually or automatically – all these operations are usually triggered from within the worker process. As the worker process account is often not allowed to write into the configuration database where SharePoint timer jobs live, it is not possible to configure the timer jobs directly.
To overcome this limitation, the configuration data for the timer jobs has to be stored within the current content database and the timer job will pick up the data from there.
WSS provides a built in mechanism for this by providing the SPWorkItemJobDefinition class. Timer job definitions derived from this class are able to read configuration data from work items, which are stored in the ScheduledWorkItems table in the content database. The Sharepoint object model allows adding, reading and removing work items to/from this table.
As many different timer jobs can work on the same ScheduledWorkItems table it is necessary to ensure that each ScheduledWorkItems carries a type information (a unique id) to ensure that the timer job picks up the correct work items.
Related to variations this means that each site or page spawn request and each variation hierarchy creation request is represented by a specific work item in the scheduled work item table. When the appropriate timer job runs the next time, it reads all work items related to this timer job from the ScheduledWorkItems table and processes them one by one. After the timer job has completed the processing of a work item, it removes the work item from the ScheduledWorkItems table.
Underlying WSS Timer Job framework
All timer job are persistable objects derived from the SPJobDefinition class.
In SharePoint 2010, a new abstract class derived from SPJobDefinition has been included, which supports pausing and restart of timer jobs: SPPausableJobDefinition.
This class declares a second Execute method, which allows to hand-in a job state to the timer job. Timer jobs derived from SPPausableJobDefinition can use this job state (SPJobState) to store values when the job is paused, which can be retrieved later when the job is resumed.
SharePoint 2007 introduced a SPWorkItemJobDefinition Timer job class derived from SPJobDefinition which provided a framework which allowed the implementation of Timer jobs which process a list of work items of a specific type.
With SharePoint 2010, SPWorkItemJobDefinition now also supports the pause and resume functionality and is now derived from SPPausableJobDefinition.
For backward compatibility reasons the class still supports Timer job definitions developed without the pausing functionality in mind.
In SharePoint 2010 the actual Timer job derived from SPWorkItemJobDefinition only has to implement two methods: WorkItemType() which returns the unique ID of the work item type that should be processed in the timer job, and ProcessWorkItem() which processes one single work item of the defined type.
The framework provided in the SPWorkItemJobDefinition base class handles the rest of the processing like reading the work items from the database, updating the Timer job progress (visible as progress bar in the central admin), pausing and resume.
Variation Timer Jobs Framework
All variation timer jobs implement the SPWorkItemDefinition class. As many variation timer jobs perform very similar operations, an additional intermediate abstract class VariationsSpawnJobDefinitionBase has been implemented which acts as base class to four of the five variation timer jobs:
Work Item type for Scheduled Variation Work Items