1 / 37

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

COM Threading and Application Architecture in COM+ Applications Michael McKeown Support Engineer Solution Integration Engineering (SIE) Microsoft Corporation. What We’ll Discuss. COM+ improvements Neutral threading model Threading model recommendations Server components and threading.

Leo
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related