...if the events for some reason are fired out of order...
They never do. The COM+ system event publisher fires these events using COM+ Events service. Invocation of an event is synchronous from event publisher's point of view. When a publisher fires an event, it doesn't proceed with the next one until all the subscribers complete processing of fired event. Quite naturally, OnMethodReturn/OnMethodException
events are not published before matching OnMethodCall
ones. I recall reading KBs concerning race conditions/broken subscriptions in COM+ events. All of those bugs, to my knowledge, have been addressed in various Service Packs for Windows 2000. Though, admittedly, I do not try to stay up-to-date in this area.
When implementing IComMethod2Events
you subscribe to the very same transient subscription as for IComMethodEvents
. So order of fired events is the same too.
...so correlation has to be done using at least
oid
andoriginal caller
...
At this point I'm really not sure whether you do interpret results of your tests correctly. How do you test, exactly?
oid
should already encapsulate all the information required, even in "multiple clients" scenario with JIT and pooling. Last time I implemented such event listener (it has been a while), relying on oid
worked out fine. Though, majority of components in my environment was written in VB6 (hence, lived in STA). Yet, even with STA you can have several calls at various stages of execution by a single thread. As there is an upper bound for number of threads in COM+ STA thread pool you can have the following situation: call A starts on particular thread, call B starts on the same thread, call B returns, call A returns. I do not recall any trouble tracking the calls by oid
without "some additional info about the caller".
Implementation idea you consider is, by large, canonical. COM+ spy
sample that comes with Platform SDKs uses oid
argument to trace individual calls. You can find the application's sources in <Path to SDK samples>\Samples\com\administration\spy
. The sample has been using this implementation for quite a while (since Windows 2003 at least). And today it is aeons after MTA and even COM+ introduction. Should there be flaws the sample would be updated at this point. Hopefully.