1

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?

|improve this question|||||
  • Ahh... the dreaded save conflict. We never found a real solution to this issue, but a hack/workaround is to add a long Thread.sleep between each cycle to ensure it has had enough time to perform the task. Try something like Thread.sleep(60000). – David Oct 29 '13 at 8:46
  • Sir,do you know the cause behind the code gets executed cycle wise when the users are added and it gets executed statement wise when user are removed? – users1100 Oct 29 '13 at 8:50
2

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.

|improve this answer|||||
  • Oh jeez, use a different pattern, never settle for Thread.Sleep. If I find concurrency problems like this I'll enforce that logic insight a Singleton with a lock object on it, to ensure only one instance can run in a process at a time. – James Love Oct 29 '13 at 9:09
  • @JamesLove We were on a very tight deadline and had to do it very quickly. I don't think we could have used a singleton in this case... – David Oct 29 '13 at 9:11
  • @JamesLove Also, it's Sharepoint that decides what to run on what thread. You have little to no power over what happens there. – David Oct 29 '13 at 9:15
  • Do we have control over to make code execute cycle wise like it is executing while adding users in my case?@JamesLove – users1100 Oct 29 '13 at 9:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.