Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Summary
This chapter looks closely at the mechanics of contexts. There is an intrinsic relationship between contexts and interface pointers. Specifically, interface pointers are context-relative resources that are inexorably bound to the contexts in which they were originally acquired. You cannot use an interface pointer acquired in one context directly from another context safely. Instead, you must translate the interface pointer into one that is appropriate for use from the foreign context using the system-provided marshaling application programming interfaces (CoMarshalInterface, etc.). This happens automatically when you pass interface pointers as parameters to COM methods or standard APIs. If you pass interface pointers between contexts in other ways, such as by storing them in global variables or passing them as input to new threads, you have to marshal them by hand using either the low-level marshaling APIs or the GIT. If you invoke the methods of an interface pointer that was not marshaled across context boundaries, the results are undefined.
There is also a relationship between contexts and objects. By default, the SCM maps new instances of most configured classes to contexts of their own. This is not a restriction of the context model. It is simply the result of the way several of the COM+ runtime services are currently implemented. The one-to-one mapping of objects to contexts produces significant overhead in both time and space. You may choose simply to accept this as the price of runtime services that you would otherwise have to implement yourself, or you may choose to reduce this overhead without losing functionality by using raw-configured classes. The SCM always puts new instances of raw-configured classes directly in their creators' contexts. They can take advantage of the services their creators' contexts provide as they see fit. They can also custom marshal. The notion of raw-configured classes may seem to go against the COM+ grain (i.e., "services are applied transparently; don't worry about the details"), but the creators of COM+ designed the runtime with the notion of raw-configured classes in mind. You should consider them an integral part of the COM+ programming model and leverage them whenever possible to make your system more efficient.