Save conflict error when handling user deletion from group programmatically

Question

I have a site in which unique permission group are there.

I want to update the list item as per the changes made in the user group in site, i.e. if user is removed from the site user group then the user from the list item should also be deleted.

My code is:

if (groupDeleted.Name.EndsWith(UserGroups.Managers.Name))
{
   DeleteUserFromList(userDeleted, FieldNames.ProjectManager, item, properties.Web);
}

The method is:

    private void DeleteUserFromList(SPUser userDeleted, string fieldName, SPListItem item, SPWeb sPWeb)
    {
        try
        {
            SPFieldUserValueCollection Users = item[fieldName] as SPFieldUserValueCollection;
            SPFieldUserValue DeletedUserValue = Users.First(u => u.LookupId == userDeleted.ID);
            Users.Remove(DeletedUserValue);
            item[fieldName] = Users;
            item.Update();
            item.ParentList.Update();
        }
        catch { }
    }

The code works fine if I delete single user from the group. But when I delete multiple users then I am getting error : Save Conflict.

One more thing I need to clarify that when I add two users and debug the program then the entire code is executed 2 times(i.e. 2 cycles) but when I delete two users then each statement gets executed two times.

What am I missing?

Answer 1

From what I could gather last time the issue occurred, this happens because SharePoint runs code on different threads and consequently can lock down items, users, just about anything. This happened to us when we were creating lots of folders and sub-folders in a multiple lists in quick succession. We could not find anything that worked after days of research. What's interesting is that the speed of the machine seems to be related with how often this issue occurs, it seems that the faster it is (and the lighter the task you are doing is) - the less the issue occurs.

This was only happening in some code that had to be executed on feature activation, so since it would only be deployed/activated once, we added a conservative thread.sleep between each cycle. It's a hack, but we could not find a better solution.

Also, what's hilarious is that if you try to attach the debugger and step through it, it won't happen, because you are giving SharePoint enough time to run the cycle.

I hope there's a better answer.