This is a problem that seems to pop up all the time, so I'm wondering if there is an authoritative answer somewhere.

I'm using an event receiver (specifically, the ItemUpdated receiverthrough the "Document Library" list type) in a Page library with publishing enabled. Whenever the publishing status of a page is changed, I want to update a separate list which contains links to certain pages which are going to be displayed on a separate computer.

I do this by deleting all the elements of this list and then adding the ones I want to be there. The problem, however, is that sometimes the ItemUpdated event receiver is called by SharePoint multiple times - perhaps because saving the page, updating the metadata and changing the publishing status all individually trigger the event.

This causes a concurrency problem. Presumably, the list operations I perform happen across multiple database requests, and hence I get the classical situation where the data my code is working on is non-deterministically changed in the middle of a method call.

So the question is, is there some way to limit the ItemUpdated calls to the specific calls I want? Or alternatively, do you have some way to handle these concurrency issues that removes some of the complexity?

2 Answers 2


I've always had to handle the concurrency issues. On SP 2010, I've done these things:

1) Set the Synchronization property of your receiver to SPEventReceiverSynchronization.Synchronous.

2) Disable event firing within the receiver methods e.g. this.EventFiringEnabled = false;

3) When working with Properties.ListItem object, check if it's not null before doing any processing.

4) Check if the item updated event was not caused by a check-in, using the following code:

if (properties.AfterProperties["vti_sourcecontrolcheckedoutby"] == null && properties.BeforeProperties["vti_sourcecontrolcheckedoutby"] == null) { }


This Stack Overflow Post has a similar issue, and as per the answers, document saved, checked in, and published trigger the event. As per another answer, you could use DisableEventFiring() at the start of your event handler, and EnableEventFiring() at the end, to ensure every time data is added, it runs to completion.

I'll have to look into checking for a publishing event rather than any others, but the above solution will at least work, if a little less efficiently than otherwise


Found a solution that checks for publish. This Link uses


to check the publishing status. Mabye that's a bit closer to what you want, although i would still use the Disable/EnableEventFiring() functions to ensure there are no issues.

  • Thanks, this is very useful. The part about checking publishing from the SPListItem not having to check the SPFile is especially useful. Commented Mar 30, 2012 at 12:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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