COM Threading and Application Architecture in COM+ Applications Michael McKeown Support Engineer Solution Integration E

1. COM Threading and Application Architecture in COM+ ApplicationsMichael McKeownSupport Engineer Solution Integration Engineering (SIE)Microsoft Corporation

2. What We’ll Discuss • COM+ improvements • Neutral threading model • Threading model recommendations • Server components and threading

3. COM+ Improvements:Just-in-time Activation (JIT) • Code • IObjectContext::SetAbort/SetComplete • IContextState::SetDeactivateOnReturn(TRUE) • Component Services explorer • Component level Enable just in time activation • Forces Synchronization = Required • Enabled if transactions checked • Method level auto-done property • Deactivate this object when this method returns

4. Object Pooling • Generic instances shared at class level • Cannot cache user-specific state • Reuse expensive resources • Save time during activation • Setting in COM+ Services • Cannot have thread affinity • IObjectControl::CanBePooled • JIT vs. object pooling

5. Synchronization • Logical boundary around mutually synchronized components • Example: Required and Supports • Set to Required if JIT or transactions • Only one thread at a time runs within this synchronization boundary • Synchronization determines when this can occur • Previously, apartments dictated this under Microsoft® Windows NT®

6. Synchronization (2) • In COM+, maps to synchronization setting • If none selected (and no JIT or TXs), component manages all its synchronization and can be called anytime • A COM+ synchronization can span many apartments and contexts • A context/apartment can exist in only one synchronization • Can span processes ONLY if you enforce it in your component architecture via call tree graph

7. Understand Call Tree Frequencies • Pay careful attention to • How a component will be used in call tree graph • Avoid blocking and odd behavior • Call only those components it instantiates directly or those instantiated below them in the tree • Avoid passing component references up or across the call tree • Avoid multiple callers into the same component • Simplifies everything and is inherently scalable • From what type of apartment the component will be called • Don’t just blindly mark as Both or Free

8. Understand Call Frequencies • Example: A creates B, which creates two Apartment components C and D • If A and B have many calls between themselves, but B has few calls between C and D • B should be Both to create in A’s apartment • If A and B have few calls between themselves, but B has many calls between C and D • B should match threading model of C and D • If B is Both and A lives in STA, B will run as STA and in same apartment as C and D – GOOD. • However, if A lives in MTA, and B is Both, it will run as Free and live in MTA – BAD! • Thus, mark B as Apartment to be close to C and D

9. Contexts • Set of run time attributes (Tx, Sync, etc.) • Tells COM+ what the required interception services are • Term context has roots in MTS • Context wrapper replaced by intelligent stub • Policy sets (interception) MTS Client Proxy Stub CW JIT instance COM+ COM+ Policies / interception

10. Contexts (2) • Each instance has a context • Shares activator’s context if all attributes compatible • Calls in the same context are direct • Configured components rarely share context • JIT, Synchronization, and transaction settings • Certain threading model values (Apartment vs. Free) • Incompatible contexts will be swapped (marshaled) from activator to component • Allows for different interception service requirements • Lightweight proxy (discussed later)

11. Contexts (3) • Can be more than one context in an apartment • A context lives in only one apartment • Default context • Unconfigured components with compatible threading model with their activator • One default context per apartment • Non-default context • Configured components with compatible attributes • Typically more than one per process

12. Default Context Object Apartment Object Non Default Contexts Object Object Contexts in a Windows 2000 Apartment

13. Compatible Contexts • Logical boundary around instances with compatible extended attributes • Attributes are service-specific plus threading model • Transactions, Synchronization, JIT • Example: Component A creating component B • Component A: Tx = Required and Sync = Required • Component B: Tx = Supports and Sync = Not Supported Note: Both components can share a transaction boundary, but not a synchronization boundary • Live in different contexts

14. Compatible Contexts (2) • CA and CC are in different apartments, but may be sharing a TX boundary • CA and CB share an apartment boundary AND may be sharing a sync boundary • CC and CE are in different processes, but may be sharing a Tx boundary P-A A-A A-B CA CC A D B CB C Process P-B A-C CE Apartment G CD E Context F Boundary

15. Object Context • Unique to each component instance • Basically same dual role as under MTS • Data structure to hold attributes such as: • TX ID, Synchronization ID, SIDS, etc. • Service component that offers COM+ services to configured components • CoGetObjectContext replaces legacy GetObjectContext • Allows access to new COM+ service interfaces • IObjectContext, IObjectContextInfo, IObjectContextActivity, IContextState

16. Object Context (2) struct OBJECT_CONTEXT : IObjectContextInfo, IContextState, IObjectContext, ... { // context properties GUID id; // ID of this context SYNCHRONIZATION *pSync; APARTMENT *pApt; bool bJITAEnabled; bool bDone; long nCallsInProgress; IUnknown *pPrimaryObject; TX_STREAM *pTxStm; bool bRootOfStream; bool bHappy; // interface methods deleted for clarity };

17. Interception and Proxies • Direct interface pointer (same apartment and context) • Threading model and contexts compatible • No interception • Lightweight proxy (same apartment / different context) • No thread switch (executes on caller’s thread) • Marshals interfaces only • Interception services • Traditional proxy (different apartment or process) • Most expensive • Thread switch • Marshals interfaces and parameters • Interception services

18. Apartments in Windows 2000 • No longer the innermost execution scope of an object for configured components • Contexts have assumed this role • Maps specific threads to contexts • Determines which threads can call an object, not when a thread can call an object • Synchronization attribute now determines when

19. Contexts, Apartments, and Synchronizations Summary • Contexts • Determine services required for method call • Belong to one apartment, but can be more than one different context in an apartment • Belong to at most one synchronization only • Apartments • Contain one or more contexts • Determine which threads can call an object • Synchronization can span multiple apartments • Each apartment exists on only one synchronization

20. Contexts, Apartments, and Synchronizations Summary (2) • Synchronizations • Typically span apartments and contexts • Ensure when serialization of calls to all components in the same synchronization • Every context belongs to at most one synchronization • If no sync, context does not belong to any synchronization

21. Threading Terminology • Apartments • Single-threaded apartment: STA • Multithreaded apartment: MTA • Neutral apartment (no ‘threaded’): NA • Confusing component terminology • Example: OCX versus ActiveX® control • x theaded component • x – Apartment, STA, Free, MTA, Neutral • Proper component terminology • y component or component marked y • y – Apartment, Free, Both, Neutral registry values

22. COM Threading • Components don’t live on threads • An instance is a ‘chunk’ of memory associated with an apartment • Apartments determine which threads can call the component • Thread switch is decided by the proxy based on apartment and threading model

23. Neutral Threading Model • Basically a Both object • FTM-like marshaling capabilities for configured COM+ components • Cross apartment (same process) used to require a thread switch • Method calls from any apartment (same process) type without thread switch • Methods execute in the (logical) Neutral apartment (NA), but on the calling apartment’s thread • COM gives back standard proxy to Neutral objects for context switch and marshaling

24. Neutral Threading Model (2) • One Neutral Apartment (NA) per process • COM creates the NA when required • NA is neutral and not bound to any threads • No threads are bound to the NA • Threads don’t enter the NA like MTA/STA • No CoInitializeEx(COINIT_NEUTRAL…)

25. Neutral vs. BothAlmost Identical • Operate well in Both an MTA and STA environment • Thread safe via synchronization primitives for MTA • Globals, statics, and members • Nothing thread specific • TLS, Windows handles, or code logic that assumes it is always being called on same thread • No operations that block STA message pump • Explicit calls to WFSO / WFMO avoided • Use new CoWaitForMultipleHandles • If called by STA, will enter loop during wait and pump messages • If called by MTA, will map to WFMO

26. Neutral vs. BothYet Different • Differ in ability to store interface pointers within the class instance data • Both with FTM cannot store interface pointers • Direct pointer passed across process without COM • Neutral components can store interface pointers • A standard proxy is returned – never direct pointer • COM ensures stored interface pointers in passed object’s instance data called on correct thread

27. Threading Recommendations • Minimize mixed threading models • Instantiate component as close to activator as possible • Same apartment and same context if possible • Understand ramifications of extended attributes • Minimize thread switching if possible • Don’t sacrifice COM+ functionality just to shave a few milliseconds!

28. Apartment Components • Recommended for MTS, but avoid in COM+ (unless called from ASP) • Unnecessary hidden window and marshaled calls through message loop • Will force Sync = Required • Serialization through synchronization for configured components • Best for page scope in ASP • Don’t store it in Session or Application scope

29. Free Components • For components making blocking calls • Implicitly during outgoing calls outside apartment or process • Explicitly using WFMO, WFSO, etc. • Not recommended for MTS • Wasted synchronization code and cross-apartment marshaling • Great for DCOM and straight COM+ • Okay for COM+ pooled objects (Neutral is better) • Not good if called from ASP (configured or not) • Better than Apartment if using JIT • Methods still serialized on synchronization lock, but not in MTA

30. Both Components • Tastes good and is less filling • Runs well in both STA and MTA • Better than Free because good for ASP • Run as Apartment under ASP • Just as good as Free for DCOM & COM+ • Unconfigured Both activated in creator’s context • Key point: MTA side must not ruin STA and vice versa

31. Neutral Components • Like Both, but no thread switch • Can store interface pointers in instance data • Good in situations where different types of apartments are calling a single component • Avoid many-to-one in server environment • Good in common local applications doing logging • Best for COM+ pooled objects

32. Server Components • MTS (STA activator threads) • Use Apartment or Both and avoid Free • Marshaling into MTA and unnecessary sync primitives • ASP (Runs as STA) • Use Apartment at page scope • Free has usual STA issues, plus • Security issues of proxy

33. Server Components (2) • DCOM (No ASP or COM+) • Incoming DCOM requests • If it’s an Apartment component, it will block the request until its specific thread is available • If it’s a Free component, call can be transferred to first available thread and no waiting • DCOM objects should be Free • Neutral does not matter in remote case • Neutral has limitation of not blocking calls

34. Server Components (3) • DCOM (with COM+) • Free is best because of COM+ MTA thread pool • Neutral is okay • No thread switch is insignificant remotely • Code to make it behave in STA could be hindrance

35. ASP Components • ASP session-scoped components (Agile) • Windows NT: Both with FTM • Windows 2000: Cannot aggregate FTM because cannot allow direct call, so choose Neutral • ASP application-scoped components • Avoid if at all possible because blocking is worse than at session scope • IIS 5.0 will not allow Apartment to be assigned to an Application variable

36. Wrap Up • COM+ improvements • Threading terminology • Neutral threading model • Threading model recommendations • Server components