MiniJIT allows just-in-time activated COM+ components to join the context of caller

This article describes a new Microsoft COM+ feature that is named MiniJIT, and how it can be used to set components with just-in-time (JIT) to be instantiated in the context of the caller.

When you use the JIT Activation service in COM+, the COM+ component must join its own context. To allow JIT-activated components to join the context of its caller, MiniJIT is included in the COM+ 1.0 Rollup fix 28. With MiniJIT enabled, a component can take part in JIT activation and can still be activated in the context of its caller. MiniJIT also makes sure that the IObjectControl::Activate method and the IObjectControl::Deactivate method are appropriately called, and that the transaction and the state of the parent (component of the caller) are not affected when the child component calls any of the following methods:

• IObjectContext::SetComplete
• IObjectContext::SetAbort
• IObjectContext::EnableCommit
• IObjectContext::DisableCommit

Note With MiniJIT enabled on a component , all the component and application property settings other than JIT that are mentioned in the following article still must be set correctly to get the component activated in the context of the caller:

Steps to enable MiniJIT

1. Make sure that COM+ Rollup 28 or later is installed on the the computer where you are creating the COM+ object.
2. Add the following value to the registry to enable MiniJIT for that computer:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\
   DWORD value: MiniJITEnabled = 1
3. Set all the component and application property settings other than JIT that are mentioned in the following article:
   261096  (http://support.microsoft.com/kb/261096/ ) How to activate a COM+ component in the context of its caller
4. In the component properties, set the following options to let the COM+ runtime determine that the object that you are creating has MiniJIT enabled:
   • Enable Just In Time Activation
   • Must be activated in callers context

You must correctly identify the candidate components for MiniJIT. Before you apply MiniJIT, you must make sure that these components can be instantiated in the context of the caller. The components must meet the following requirements:

• These components must not make use of any COM+ services other than JIT (if necessary).
• The component or the components that have MiniJIT enabled must always be called from another component or other components in the same process. The components that have MiniJIT enabled should not be called from component or components, or a client or clients, in another process. Microsoft recommends that you add components that have MiniJIT enabled to a Library package. This makes sure that the object is created in the process of the callers.
• The component or the components that have MiniJIT enabled must always be called from another component with the same threading model. This make sure that the component or the components can be instantiated on the same Thread or Apartment.

If you do not meet these requirements, the component instantiation may fail with the following error:

Differences between normal JIT and MiniJIT

• The ObjectControl_Activate method for the MiniJIT object is called immediately after you create the object and not when the first method is called. In a typical JIT scenario, the ObjectControl_Activate method is called when the first method call is made.
• The ObjectControl_Deactivate method for the MiniJIT object is only called when the calling object is destroyed. The Deactivate method of the MiniJIT object is not called immediately after the SetComplete method or the SetAbort method call is made. The Deactivate method is not called even after its last outstanding reference is released. In the typical JIT case, the ObjectControl_Deactivate method is called after the SetComplete method or the SetAbort method, or when the last reference is released.

Contexts, which are specific reference entities where objects reside, were introduced in COM+ 1.0. In Microsoft Transaction Server (MTS), the most specific reference entity was an Apartment. In COM+, more than one context can be in an Apartment. Two components that are in the same Apartment can reside in two different contexts. Any calls between these two components are marshaled if they do not reside in the same context. The marshaling process can introduce a performance overhead based on the number of new contexts that are created, cross-context calls that are made, and the type and the amount of data that is transferred in those calls. Contexts were introduced in COM+ to provide interception logic for COM+ features. Any object that uses interception-based COM+ services has its own context.

For more information about Contexts and COM+ threading models, visit the following Microsoft Developer Network (MSDN) Web site:Because the services that are set on a component and its package may end up creating a new context for that component, every call that is made to such a component from other components outside its context must cross the context and must be marshaled.

If a component in a DLL is registered with COM but does not belong to any COM+ package, it will be invoked in the context of the caller component. This component is an unconfigured component. Calls to this component do not cause the overhead of cross-context marshaling.

A component that belongs to a COM+ package can be made to instantiate in the context of the caller by disabling the COM+ services that requires interception. These are raw-configured components. For additional information, click the following article number to view the article in the Microsoft Knowledge Base: Raw-configured components do not cause the overhead of cross-context marshaling.