SharePoint: Timerjobs lock type
I am trying to create a timer job in WSS 3.0. A timer job would create an SPsite object, then an SPWeb, and then an SPDocumentLibrary (or possibly an image library) using their GUIDs stored in any xml or database. Thereafter, back up the documents in the document library in a third party application and then delete those documents.
So my question is, what should my SPJobLockType be "None" or "Job" or "ContentDatabase" ideal? ... The following is my understanding after reading some articles about timer operation. Please correct me if I am wrong anywhere as I am completely new to SharePoint
-
If I use No, my work will run on every server in the farm. Do I really need this? because my job is only to change / delete documents (I only modify the content database via my timer job. Please correct me if I'm wrong).
-
If I use the "Job" lock type, then my work will only be executed on the server that is running the job creation code. But it can fulfill my requirement (I think so, but I'm not sure, please correct me if I'm wrong).
-
I read this article for ContentDatabase LockType .. It says
in short, its almost the same as Have one, which means it only starts one server .. BUT .. as Peter finds out in Help needed for custom timer in SharePoint 2007, work is done for each ContentDatabase, WebApplication is associated with ... Another (rather annoying) fact is that it is not as predictable when it will run on the next content database.
Please give your thoughts / suggestions.
source to share
Anoop,
The type of sweep timer job you describe is fairly common, and I've written several of them for different projects. In this type of timer job, you process a set of sites, web pages, or lists to perform some kind of maintenance. It is usually easier to process one site / web list at a time, and the task being executed is not the type that needs to be done at maximum speed (i.e., which requires a parallel / multithreaded processing model to complete quickly).
In this type of scenario, I tend to create timer jobs to use the SPJobLockType for "Job". As you noted, this ensures that only one instance of the timer job is running at any given time in the farm. This avoids the collisions that can occur if multiple instances were executed with SPJobLockType "None" and also avoids the convoluted (at least I find it confusing) mechanism of operation associated with the SPJobLockType "ContentDatabase".
Here's a link to a timer job that I wrote and posted on CodePlex. It does the same type of sweep (at a slightly higher level) that you described: http://blobcachefarmflush.codeplex.com/SourceControl/changeset/view/53851#797787 . The timer job is instantiated in the FeatureReceiver with the following line of code:
BlobCacheFarmFlushTimerJob newJob = new BlobCacheFarmFlushTimerJob(jobName, housingWebApp, null, SPJobLockType.Job);
Based on my understanding of what you have written, I believe that the SPJobLockType "Job" would be appropriate. You want only one instance of your job to run at a time (to prevent one or two instances of the same job from trying to process the same SPSite).
I hope this helps!
source to share