Adrian Bateman pointed me towards this great article on EnterpriseServices. It covers a lot of details, although it doesn't fully answer my questions. I wanted, however, to point out one part of the document I think is particularly dangerous. It reads:
"When the root object gets created, the associated unmanaged context is created and associated with the current thread. When a call to the child objects is made, since they are not associated with an unmanaged context, no COM+ context change is needed, hence the thread still maintains the roots unmanaged context id. When a child object calls on resource managers, the resource managers will in turn extract the unmanaged context from the thread executing the child object, which is the root objects unmanaged context. Relying on this is dangerous and in future versions the unmanaged context may merge with the managed context and therefore the child objects will be associated with a potentially different managed context; the resource managers will not pick up the root objects context. Therefore, upgrading to a new version of .NET could break code that depends on this type of behavior.
"
The implications of the last part of this paragraph are huge, and if that ever happened, my opinion would be that it would seriously hinder EnterpriseServices in .NET, and make it much more complex and problematic to use. In other words, I most definitely would not like having to make almost all my classes ServicedComponent-derived.
There's hope, however. A couple of weeks ago, a discussion on this topic popped up on the microsoft.public.dotnet.framework.component_services newsgroup, where Craig Critchley, from MS, talked about this topic. You can read the relevant comments here, here and here. His answers also helped answer some of my questions (although I think I don't fully understand what's going on, yet).
1 Comment
archived from WordPress — closedI can't remember that I heard that the unmanaged context will ever merge with THE managed context as we know it. If you look at the relevant COM+ patent and compare that against what the Remoting context has to offer, it becomes quickly apparent that the unmanaged context has more functional depth and therefore can't be mapped onto the managed context as it is existing today. So, I would rather say that using the managed context today is a risky thing in terms of future compatibility and one should consider that MS pulled the docs on that going from Beta2 to RTM.
Hint: Try implementing "IsContextOK" with two ContextAttributes correctly so that both work and you'll know where the managed context has its limits. Next excercise: make that context flow.