"Neutral" Versus "Both" Components

[thiruvasagamani]

"Neutral" Versus "Both" Components

The design of "Neutral" and "Both" components are very similar, but they differ significantly in how they store interface pointers. Objects that live in the neutral apartment (NA) receive incoming calls from any thread, and yet these objects always execute in the caller's thread. This is similar to objects with components that are marked "Both" that aggregate the FTM. The difference is that when an interface pointer to a "Both" with FTM component is marshaled across apartments in the same process, a direct interface pointer is passed to the caller instead of a marshaling proxy. The caller can directly call the component. There is no proxy through COM marshaling, nor is COM+ involved here. This is why such objects, also named "agile" objects (see the Server Components section), cannot store interface pointers to objects that do not aggregate the FTM as their instance data. Because COM is not involved in this scenario, the component cannot ensure that any of the interface pointers that it holds are called from a thread that belongs to the apartment where the interface pointers were created. "Both" with FTM objects should resort to the Global Interface Table (GIT) to store such interface pointers and store an apartment neutral cookie as their instance data.

Unlike "Both" with FTM components, objects that are marked "Neutral" can indeed store interface pointers within their instance data. This allows COM to ensure that the stored data member interface pointers are called in the proper apartment in which they were created. "Neutral" objects are always called on the same thread as the caller, but these calls are not direct due to a standard proxy. This is unlike "Both" with FTM components, whose methods are called directly. Neutral instances have a standard proxy/stub between themselves and the activator due to the need for COM+ interception.

For "Both" with FTM components, COM can return direct pointers when they are in different contexts. Under COM+, this can cause all kinds of problems if in different contexts because it means that the call circumvents interception. For configured "Both" objects that aggregate the FTM, COM+ simply ignores the FTM whether or not you aggregate it. The neutral threading model is the closest that you can get to the FTM while maintaining COM+ service semantics. This ensures that contexts are swapped during calls within the same apartment and that interface pointers and data are marshaled correctly, but no thread switch occurs.