I am working on a SharePoint 2010 integration that has an SPItemEventReceiver for handling ItemAdded and ItemUpdated events for the Document library list. I have added a constructor to handle some initialization for the event receiver. In testing/debugging I have noticed that when my feature is activated (the feature containing this event receiver) my event receiver is initialized 12 times. I have been trying to figure out why the constructor is called 12 times and wondering if all 12 instances are going to be alive until the feature is deactivated or if I need to be careful as some of them may be garbage collected down the road. Anyone know why there are 12 and what their lifetime is?
A:
I wouldn't say the magic number 12 is relevant; it's just scaling for you. Regardless, SharePoint event receivers should not depend on singleton semantics. What's important is that for each unique event, you can be sure that only one of these event receivers will handle the event, unless you accidentally added 12 to the same list ;-)
-Oisin
x0n
2010-08-10 20:47:05
So this would probably be the same, even if I added it in my feature activated programmatically as opposed to allowing the "wsp" packaging to handle the deployment. Is there any way to get "singleton" initialization semantics for an event receiver. My goal is to set up some folder watching in another thread.
pstrjds
2010-08-10 20:50:17
I guess another question I should ask is, is you mentioned "SharePoint event receivers should not depend on singleton semantics" is there some documentation along those lines? I am not doubting it, I am new to SharePoint and web style development, I have been doing desktop C++/COM/C# development for several years.
pstrjds
2010-08-10 20:52:15
There isn't any documentation on that particular point for event receivers, but there more you do web development you'll realise it applies to everything. HTTP is stateless, regardless of how ASP.NET uses viewstate to make you think otherwise. Trying to assume that only one person will execute your aspx page at any one time is a good analog. The web is all about parallelism, and this reaches deep into the stack.
x0n
2010-08-11 20:27:11
Thanks for the responses, I am beginning to understand/see the whole stateless situation, just have to get my mind around developing for it. I have done lots of multi-threaded stuff on the desktop/server side, but the jump into Asp.Net/SharePoint has been a conceptual leap into a new deep/dark pond. I have been able to work around the concept and get a singleton like behavior by creating a lock file on the disk (this is all internal and using a UNC path so it is visible). This allows only 1 thread to actually continue executing. It may be a hack, but it works for me :)
pstrjds
2010-08-13 14:31:52