Skip Ribbon Commands
Skip to main content

Robin | zevenseas | SharePoint Blog


The zevenseas Community > Blogs > Robin | zevenseas | SharePoint Blog > Posts > About custom Timer Jobs and SPJobLockTypes
April 24
About custom Timer Jobs and SPJobLockTypes

If you are just starting with creating your own custom timer jobs, you probably run into the posts of AC (Creating Custom SharePoint Timer Jobs , MOSS Timer Jobs - Create Your Own!) and his MSDN article Creating Custom Timer Jobs in Windows SharePoint Services 3.0 and you start using the examples provided and build your very own first timer job right? (I know I did .. and if it wasn’t for his posts and articles in the first place, this post wouldn’t exist ;)

So what is this post about then? Well.. in all the examples provided you will see when defining the timer job the SPJobLockType is set to “ContentDatabase”.

public SharePointWarmupJob (SPWebApplication webApp)
      : base(Globals.JobName, webApp, null, SPJobLockType.ContentDatabase) {
      this.Title = Globals.JobName;

And when referring to the SDK for explanation this is what it says :

- SPJobLockType.ContentDatabase   Locks the content database associated with the job
- SPJobLockType.Job   Locks the job to prevent multiple instances of the job from running on a single server
- SPJobLockType.None   No locking.

There is another post called Where is My Timer Job? by Scot Hillier where he tests what the real difference is between the Job and the None LockTypes and he discovers when setting these timerjobs in a multi server farm that the Job LockType ensures that it only runs on one server. And the None ensures that the job runs on every server.

But Scot doesn’t mention what happens if you use the ContentDatabase LockType.. in short, it’s almost the same as the Job one, meaning that it only runs one server.. BUT..  as Peter find out at Help needed with custom timerjob in SharePoint 2007 , the job runs for each ContentDatabase that the WebApplication is associated with. Another (quite annoying) fact is that it is not that predictable when it will run on the next content database.

This usually is being discovered when the timer job is already in production (it’s pretty safe to assume that most developers don’t have multiple content databases associated with their WebApplications..) and at that time you don’t have a clue why it’s displaying this kind of behavior.

So if you are not doing stuff that is bound to a specific ContentDatabase (like moving or backing up sitecollections (since sitecollections are stored per contentdatabase)) you are most of the time better of using the Job SPLockType.


Technorati Tags: ,



You have awesome timing!  hehehe  I was just looking at making my first custom job timer!  I'll have to see how it goes.
System Account on 24/04/2009 08:56


Let me know how you succeed and if my post was helpful enough ;)
System Account on 25/04/2009 04:48


Thanks for mentioning me in your post :) and thanks to Twitter you provided me with the solution.

Peter - @knightparsifal
System Account on 04/05/2009 05:19


Views: 9276
Comments: 3
Published:2168 Days Ago