Feb 8, 2010
(0 votes)

Subscription job deadlock on site with large number of users

On web sites with large number of users you may get a deadlock in the SQL-server when executing the EPiServer subscription job.

The error message is something like this: Exception has been thrown by the target of an invocation. [Transaction (Process ID 105) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.]


Cause of the error

The error comes from the SQL-server when the subscription job executes the method ProfileManager.GetAllProfiles(). From my investigations the error appears when users are registering to the site during this method is executed. On large sites this is a very common situation. Users do register all the time.


I have used Reflector to copy all code in EPiServer’s class SubscriptionJob to a new customized subscripttion job.

I made some changes to the code. First of all there are some code that could be optimized. In my application the execution time for the subscription job has gone from 30 to 6 minutes, by implementing this fix.

In the method protected virtual int SendSubscriptions(EPiServerProfile profile) there is no check if the user does subscribe to any pages or not. When you have large number of users and also a custom membership provider this will cause the job to run very slow. The PrincipalInfo of the users is fetched for all users. The method GetUser will be called for all users in the membership provider.
Some small changes to the code will fix this issue. Just check if the profile does subscribe to more than zero pages.

   1: protected virtual int SendSubscriptions(EPiServerProfile profile)
   2: {
   3:     int num = 0;
   4:     if (profile.SubscriptionInfo.SubscribedPages.Count > 0)
   5:     {
   6:         IPrincipal principal = PrincipalInfo.CreatePrincipal(profile.UserName);
   7:         foreach (SubscriptionDescriptor descriptor in profile.SubscriptionInfo.SubscribedPages)
   8:         {


The solution to the real problem is more difficult. I have been able to get rid of many deadlocks but not all.

The profiles are fetched in blocks of 1000 in the subscription job. Between every 1000 some work is done for sending subscription emails to the users. This takes some time. For the next 1000 users it can be a deadlock. I think this occurs if a new user have registered during this time.

I tried to increase the pageSize for the methodProfileManager.GetAllProfiles() to decrease the time between the first and the last profile. The deadlocks are almost gone. Is there any reason why EPiServer do this job in page sizes of 1000? Is there a better solution to this problem?

   1: protected virtual string InternalExecute()
   2: {
   3:     int num3;
   4:     ProfileInfoCollection infos;
   5:     int num = 0;
   6:     int num2 = 0;
   7:     int pageSize = 200000;
   8:     Label_0004:
   9:     infos = ProfileManager.GetAllProfiles(ProfileAuthenticationOption.All, num2++, pageSize, out num3);
  10:     if (infos.Count != 0)
  11:     {
Feb 08, 2010


Sep 21, 2010 10:33 AM

Thanks for sharing. Nice optimize trick
/ Anders Hattestad

Sep 21, 2010 10:33 AM

Great info.
/ Per Nergård

Please login to comment.
Latest blogs
Optimizely SendGrid SMTP host is deprecated

SendGrid is a services for sending email that is included in Optimizely DXP. Previously was the recommended SMTP server to use,...

Tomas Hensrud Gulla | Dec 4, 2022 | Syndicated blog

Hosting Optimizely CMS 12 on Docker Engine

Since Optimizely CMS can now be deployed as a Docker container, here is a demonstration of building, running and scaling an Optimizely CMS 12 site ...

Stefan Holm Olsen | Dec 4, 2022 | Syndicated blog

How to use CacheTagHelper with content areas in Optimizely CMS 12

I might be going out on a limb here - if you have a better solution, feel very free to share it!  Upgrading your Optimizely web application from .N...

Andreas J | Dec 2, 2022

The 1001st Piece in your 1000 Piece Puzzle: .NET Default Interface Functions

I was recently working with a client who wanted a reasonably large subsystem added to Optimizely that would add automated management to their...

Greg J | Nov 28, 2022 | Syndicated blog