SharePoint Timer Job – SPJobLockType

There are 3 SPJobLockType  available:

1.       SPJobLockType.None -- if you set it none, the instance will run in all the available servers in the Farm (e.g. Application Server Timer Job)
2.       SPJobLockType.ContentDatabase – this will cause 3 instances to be running in each of the Web-Frontends.
3.       SPJobLockType.Job – this will cause only one instance of the job to run on any of the front-end servers. (Note: it is possible to see multiple instances listed in the Job Status .. but if you look at the time it was last run.. only one would have run lately)

If you have to develop a job, you have to first decide on the type of lock you need for your job.

E.g. If your job does something with the files in the Web-Frontend server you might want to use a ContentDatabase lock.. or if you have something that manipulates the data in a list.. you will have to use Job lock.
Note: If you use other types of locks to manipulate the data in a list.. the multiple job instances will run simultaneously and cause Data Update conflict errors.
Note: If for any reason you re-deploy your job.. either put the dll directly in GAC or deploysolution.. make sure you restart the 'Windows Sharepoint Services Timer' service. (OWSTIMER.EXE)Note: The account used by the Timer service should have access to the Content Database.

Here are some sample code(s) of a custom timer job definition:

[Guid("{62FF3B87-654E-41B8-B997-A1EA6720B127}")]

class MyTimerJob1 : SPJobDefinition

{

    public MyTimerJob1()

        : base()

    { }

    public MyTimerJob1(string name, SPService service, SPServer server,

        SPJobLockType lockType) : base(name, service, server, lockType)

    { }

    public MyTimerJob1(string name, SPWebApplication webApplication, SPServer server,

        SPJobLockType lockType) : base(name, webApplication, server, lockType)

    { }

    public override void Execute(Guid targetInstanceId)

    {

        //Execute Timer Job Tasks

    }

}

Remember that the different server roles that we can find on a Sharepoint farm are:

• Database Server: the server that hosts the Microsoft SQL Server database for the farm. Since Sharepoint Foundation is not typically installed in this server, no jobs will run here.
• Web Front End Server: server where the Microsoft SharePoint Foundation Web Application service is running on.
• Application Server: Any other Sharepoint server.

Here are a couple of examples on where the jobs will run depending on the parameters passed to the constructor:

//Job associated with a web app, no server in particular and none lock:
//  will run on all fron end servers.
var jobRunningOnAllFrontEndServers = new MyTimerJob1("mytimerjob", 
    SPWebApplication.Lookup(webAppURI), null, SPJobLockType.None);

//Job associated with a web app, one front end server and job lock:
//  will run only in the frontEndServer1 server.
var jobRunningOnAParticularFronEndServer = new MyTimerJob1("mytimerjob", 
    SPWebApplication.Lookup(webAppURI), fronEndServer1, SPJobLockType.Job);

//Job associated with a webApp, and an app server and lock type job: 
//  it won't run on any server since the server specified is NOT running 
//  the Web Application Service
var jobRunningOnNoServer = new MyTimerJob1("mytimerjob", 
    SPWebApplication.Lookup(webAppURI), appServer1, SPJobLockType.Job);

//Job associated with the timer service, a particular app server and none lock:
//  will run on the appServer1 server only.
var jobRunningOnAppServer = new MyTimerJob1("mytimerjob", 
    SPFarm.Local.TimerService, appServer1, SPJobLockType.None);