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.