ItemEventReceiver lifetime

Question

When I register an ItemEventReceiver to a List in a SharePoint farm, when & where will it get instantiated, and when & where will its event-handling-methods be called?

The options I could imagine:

1. Instantiated ONCE on ONE server in the Farm
2. Instantiated ONCE on EVERY server in the Farm
3. Instantiated MULTIPLE TIMES on EVERY server in the Farm
4. Instantiated ONCE for EVERY active item, then garbage collected after item is inactive for some time (so if an eventreceiver instance for an item gets created on one server, there will be no more instances be created on any server, until this event receiver gets garbage collected)

If options 2 or 3 are the case, can events for the same item be fired on different instances? Or will events for the same item always fire in the same instance? For example: there is one event receiver instance on server 1, and 2 instances on server 2. Now item X gets updated 2 times in a row. Is it guaranteed that always the same of those 3 instances handles the event?

UPDATE

As I don't get the answers I need, I'll provide some background why I need this information:

I'm developing a software that listens on every file upload or change. When the event fires, an external software gets notified via a HTTP request. The software then modifies the file and uploads it back to sharepoint. To do so, it checks it out, adds some fields to the file, updates the content and then checks it back in. Those operations trigger the SPItemUpdated event again multiple times.

But of course, for those events, I don't want to notify the external software again. The EventReceiver needs to keep track of when the external software starts modifying the file and when it's done and ignore events in between for the specific files.

To find a good strategy for this, it is very important to know the lifetime of an eventreceiver object. For example, if the eventreceiver only runs once, I can keep track of the state of the files in memory. Instead, if the eventreceiver gets called multiple times, every eventreceiver will have it's own states and it would not work. Except there is some guarantee that a file is never processed by different instances, then it would not matter.

I hope you understand now, that is indeed important to know the lifetime of an instance.

Answer 1

I'll add my 2 cents.

If event receivers were developed with care and best practices, it should run only once. And always runs on a web front end server (w3wp) in normal circumstances. When you Add/Update list items via Console APP on the server or via PowerShell - the receiver will run as part of the console or PowerShell process respectively. If TimerJob updates list item - then the event receiver will be executed inside OWSTimer.exe.

Reasons why event receivers might run more than once:

• The same event receiver was registered multiple times
• It was registered both for Added and Adding/ Updated and Updating events
• If you created an event receiver for the document libraries. Every time you upload a new document - Item Adding/Added will be followed by Updating/Updated. If you use the same instance of the event receiver for all of these events - it will be run multiple times.
• Event receivers call each other in a sequence.
• There is a Workflow process that updates your list item

Answer 2

If you update a Listitem in a ItemUpdated EventReceiver and call an item.Update() inside this receiver, you fire new ItemUpdated Events. To prevent this behavior, you can set EnableEventFiring to false. As far as i know, this will disable eventfiring for the entire SiteCollection, but there is no other "out of the box" way to do this :(

Disable Events from firing new Events

Answer 3

Updated to match revised question

The lifetime of an event receiver object is for the action occurring. For example, if you were to override the ItemAdding event you intercept the item as it is before it is added. Obviously an item can only be added once, so ItemAdding (before it is actually added) and ItemAdded (immediately after its added) will only execute once.

OnUpdated events will occur anytime the item is changed. This would include files being renamed, metadata being added to the item by updating fields, or updating the document. Items can be updated multiple times, so this event will fire every time. It will not fire at the same time as ItemAdded.

To suit your scenario, you would want to use the ItemAdding event to capture the item and document prior to it being added to the library. You can then contact your 3rd party software, receive the metadata, add the metadata to the item, then allow the procedure to continue.

Since the ItemAdding or ItemAdded event only fires when the document is originally added to the library, you don't have to worry about multiple outside calls.

ItemAdding Event Receiver on MSDN

Answer 4

Have a checkbox on your list "External Software Modified."

Have the external software always check that box when making a change.

Have the ItemUpdated event receiver check this field. If it's checked, do not execute the rest of the code. At the end of ItemUpdated, always uncheck "External Software Modified" and save with event firing disabled.