SharePoint Variations – The complete Guide – Part 17 – MOSS 2007 vs. SP 2010

Timerjob changes

In MOSS 2007, various variation specific operations were executed in the worker process of the actual web application rather than in a timer job. That caused a problem with large sites – especially on 32-bit systems – as the memory resources available to the worker process had to be shared between the variation operations and worker threads, which were handling web requests.

In MOSS 2007, only two operations were handled in timer jobs:

• Automatic creation of site variants (handled in the SpawnSitesJobDefinition timer job)
• Automatic creation of page variants (handled in the PropagateVariationPageJobDefinition timer job)

As some of the remaining operations – e.g. creating new variation hierarchies for an existing variation system – could run for many hours, it was possible that the configured application pool recycling intercepted the variation operations, which led to partially propagated content between source and target.

With SharePoint 2010, the design has been changed in a way that the critical functionality has been moved out of the worker process and into a timer job.

The following operations are affected by this design change:

• Creation of variation hierarchies (now handled in the CreateVariationHierarchiesJobDefinition timer job)
• Manual creation of sites and pages (now handled in the CreateVariationPageJobDefinition timer job)
• Manual update of a page variant (now handled in the CreateVariationSiteJobDefinition timer job)

Another important change is that all the variation timer jobs are now pausable and support recycling of the SharePoint timer service.

UI Changes

Most of the remaining differences are a side effect of the fact that the operations are now no longer executed as long running operations (LRO) but as timer jobs executed in a different process.

Due to this change, operations executed in the UI are now no longer executed when the user request the operation in the UI but when the timer job runs next.

That means that UI actions, which previously started a long running operation in the worker process have been changed to an action which only enqueues the operation for a scheduled timer job.

For a user, this change can have a significant impact on the workflow of an author as he now has to wait for the timer job to be executed before he can work on the target items.

If the default schedule of the timer jobs is used that means, the user has to wait until the next day for the creation of a variation hierarchy when a new label is created, and for up to one hour for each page that needs to be variated.

Logging Changes

Variations logs are much more stable and reliable in SharePoint 2010 than in MOSS 2007. In MOSS 2007 there were many situations where variation propagation failed without helpful information in the Variation log – sometimes the entry was there but empty.

In SharePoint 2010 the variation log is much more stable and usually it is possible to pinpoint the reason for a failed propagation through just this log.

Another change in logging are the ULS log categories used by the content deployment and migration API.

In MOSS 2007 the Content Deployment and Migration API used mainly the Upgrade category while in SharePoint 2010 it uses the Content Migration and Topology category.