moss 2007中事件触发两次.

转贴:Why event handlers are triggered twice?

A lot of people call me Mr Event Handlers (ok, that is not 100% correct. Currently I am the only one calling me that, but never mind), but today's article comes from a Friend who we will refer to as Antin.
Antin did some research on why event handlers behaved strangely in publishing sites and emailed me the results. He logged every event that happens when you check-in a file in a publishing site, and logged the thread of each call, along with the time, so he figured out the sequence.

I think his results are important for all of us writing event handlers - we need to know what is happening when. If you do find this helpful, post a "thank you antin" comment on this post, and I will make sure he know about it (enough encouragment and he may start his own blog, the lazy bugger).

The test results:
(In brackets will be thread number, then list item is old/new, then before properties is old/new, then after values is old/new) Change AND Check-in:
1. Updating (10; old; old; old)
2. Updating (10; new; new; new)
3. CheckingIn (10; new; new; new)
4. CheckedIn (15; new; new; new)
5. Updated (11; new; new; new)
6. Updated (1; new; old; old;)

Change AND Save:
1. Updating (10; old; old; old)
2. Updated (12;new; old; old)

Check-in ONLY
1. CheckingIn (9; new; new; new)
2. CheckedIn (11; new; new; new)
3. Updated (13; new; new; new)
4. Updated (10; new; new; new)

Publish ONLY
1. Updating (1; new; new; new)
2. Updated (13; new; new; new)

If you look at what happens for the save only and the check in only and the combination of new/old values it looks like it working like this:
1. ItemUpdating - from the Save event
2. ItemUpdating - from the CheckIn event (which should fire after the Updated from the Save)
3. ItemCheckingIn
4. ItemCheckedIn
5. ItemUpdated - from the CheckIn event
6. ItemUpdated - from the Save event