World is now on Opti ID! Learn more

erik.engstrand@precio.se
Feb 8, 2010
  4801
(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.]

image

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.

Solution

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

Comments

Please login to comment.
Latest blogs
Make Global Assets Site- and Language-Aware at Indexing Time

I had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This co...

dada | Jun 26, 2025

The remote server returned an error: (400) Bad Request – when configuring Azure Storage for an older Optimizely CMS site

How to fix a strange issue that occurred when I moved editor-uploaded files for some old Optimizely CMS 11 solutions to Azure Storage.

Tomas Hensrud Gulla | Jun 26, 2025 |

Enable Opal AI for your Optimizely products

Learn how to enable Opal AI, and meet your infinite workforce.

Tomas Hensrud Gulla | Jun 25, 2025 |

Deploying to Optimizely Frontend Hosting: A Practical Guide

Optimizely Frontend Hosting is a cloud-based solution for deploying headless frontend applications - currently supporting only Next.js projects. It...

Szymon Uryga | Jun 25, 2025

World on Opti ID

We're excited to announce that world.optimizely.com is now integrated with Opti ID! What does this mean for you? New Users:  You can now log in wit...

Patrick Lam | Jun 22, 2025

Avoid Scandinavian Letters in File Names in Optimizely CMS

Discover how Scandinavian letters in file names can break media in Optimizely CMS—and learn a simple code fix to automatically sanitize uploads for...

Henning Sjørbotten | Jun 19, 2025 |