SPJobLockType

Architecture:


There are 8 Servers in all..1 Database Server
1 Mail Server
2 Web-FrontEnds
4 App Servers (out of which one is the Central Admin and also a Web Frontend)

Observation:



If you take a look at the Job Status in the Operations tab of the Central Admin, we can see that some jobs are running 6 instances, some 3 and some 1 instance.

The number of instances is controlled by the SPJobLockType parameter that has to be passed to your job constructor. ( For a guide to creating custom jobs refer Andrew Connell's article
  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.

Comments

Popular posts from this blog

Sites.Selected | Graph API SharePoint Permission

Configure the SharePoint Online App Catalog

Azure Function | Sharepoint List item | Call from Power Automate Flow