SharePoint 2010 Internals - Timer Jobs

Introduction

SharePoint Timer Jobs are the heartbeat of any SharePoint Farm. They perform many important background tasks and generally consume substantial amounts of memory. Hence it becomes important to understand the ins and outs of these jobs - their location, scope, security aspects, customization aspects and performance related aspects.

The SharePoint Timer Job Service is a Windows service for The SharePoint Server. A Windows service is a long-running executable that runs in its own Windows session and performs specific functions that are designed to not require user intervention. This service should not be confused with other SharePoint Service Applications like Excel Service Application, Word Service Application, Business Data Connectivity Service, and so on. Those are web services as shown below whereas the SPTimer Job service is a Windows service.

Physical Location

The SharePoint timer job process - OWSTimer.exe - runs on all servers on a SharePoint farm. It does not have a SharePoint Admin GUI from where it can be stopped. We need to locate the Windows service and stop it manually on each server. Each timer job is either associated with a SharePoint Service Application or a SharePoint Web Application. If the service is provisioned for a web application, then only then will the related timer jobs be executed. A job can also be associated with a specific server and if the service is provisioned on that server then the job will run. The picture below depicts this.

Preferred Web Server for Timer Jobs

Using a new option in SharePoint 2010 Central Administration, we can now set the preferred server where the timer service runs. To do this, click on the Manage Content Databases menu of the Application Management section of SharePoint Central Administration. Then click on the content database and scroll down to the setting for The Preferred Server for Timer Jobs. The web server can be chosen from the ones available in the farm as shown below. In the custom timer job, we can also specify the server on which the job should run.

State machine workflows are saved in the content database. SharePoint executes workflow instances in one of two places depending on the last action. If the last action in the workflow was waiting on a user input, the workflow continues to execute on the Web front end where the user completed that input. If the workflow is continued from a delay timer or from an event being received elsewhere, it executes within the timer service. If the preferred server is mentioned – it executes on that server.

Privileges of OWSTimer.exe and W3wp.exe

The SharePoint timer job process - OWSTimer.exe - runs under the full trust execution model under the service account setup for it. This typically has higher permission levels than the IIS worker process - w3wp.exe. The application pool identity is essentially what the ASP .Net code of the portal site will be executed as. The Farm Account, which is used for the SharePoint 2010 Timer service and the Central Administration site, is highly privileged and should not be used for other services on any computers in the server farm. The account used by the Timer service should have access to the Content Database. We cannot elevate privileges in a SharePoint job so we are restricted to the permissions granted to the OWSTimer service account.

Logical Scope of Action

All timer jobs have a scope of action and an object type upon which they are intended to work. This scope is reflected in the three values of the SPJobLockType enum: Job, None, and ContentDatabase.

• SPJobLockType enum: Job - the farm - for each iteration of a job, it is expected to execute once per farm.
• SPJobLockType enum: None - an individual server - for each iteration of a job, it is expected to execute once per server, but only if the parent web application or service application with which the timer job is associated has been provisioned to that server.
• SPJobLockType enum: ContentDatabase - a content database - for each iteration of a job, it is expected to execute once per content database associated with the web application. If there are ten content databases for the web application, then the timer job will run ten times. Content database locks expire after 10 minutes, a value which cannot be changed.

When writing our own custom timer job, we have to first decide on the type of lock we need for the job. The following are some examples.

• If the job does something with the files in the WFE server we should use a ContentDatabase lock. Examples of Content Database jobs are the Backups, Expiration and Hold Processing jobs, the Immediate Alerts jobs, the Audit Log Trimming job, and the Recycle Bin cleanup job. These jobs are associated with a Web Application (or all Web Applications) and consequently run for each content database in the Web Application.
• If we have something that manipulates the data in a list we should use a Job lock. If we 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.
• Examples of jobs scoped to servers - Lock Type: None - are the Config Refresh job, Timer Recycle job, and Timer Locks job.

The custom job should not be long-running since if it is then it will severely affect the performance of the farm.

Tracking Locks

Content Database Locks are tracked by an entry in a table - TimerLock - in each content database associating the database with a single server in the farm as shown below.

Acquisition and maintenance of content database locks for a server is handled by the Timer Service Lock Management job (job-timer-locks). Content database locks are handled at the server and database level, not at the individual job level. That is, a server that acquires a lock for a given content database takes responsibility for executing all jobs for that database. No other server in the farm will execute any jobs for that database.

Job Locks

Job Locks to ensure only one server runs each job with a lock on the scope of the farm; locks are associated with a single specific server via a table in the Configuration Database – TimerLocks as shown below.

Once taken by a server, the lock is typically held by the same server until the Timer Service on that server is stopped. By default, job locks time out after 20 minutes - which means that when all is functioning properly the Refresh job will ensure no lock ever times out.

Custom Timer Jobs

Timer Jobs in SharePoint have to be deployed in the GAC because the timer service is a separate process and runs as the full trust execution model. With the assembly deployed to the GAC, we can now deploy the timer job to the Windows SharePoint Services farm.

In the next article, we will see how to write a custom timer job and deploy it.