Skip this Video
Download Presentation
COM Threading and Application Architecture in COM+ Applications Michael McKeown Support Engineer Solution Integration Engineering (SIE) Microsoft Corporation

Loading in 2 Seconds...

play fullscreen
1 / 37

com threading and application architecture in com applications - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'com threading and application architecture in com applications ' - Leo

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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

what we ll discuss
What We’ll Discuss
  • COM+ improvements
  • Neutral threading model
  • Threading model recommendations
  • Server components and threading
com improvements just in time activation jit
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

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
  • 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®
synchronization 2
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
understand call tree frequencies
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
understand call frequencies
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
  • 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)










Policies / interception

contexts 2
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)
contexts 3
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
contexts in a windows 2000 apartment

Default Context




Non Default Contexts



Contexts in a Windows 2000 Apartment
compatible contexts
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
compatible contexts 2
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






















object context
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
object context 2
Object Context (2)

struct OBJECT_CONTEXT : IObjectContextInfo, IContextState, IObjectContext, ...


// context properties

GUID id; // ID of this context



bool bJITAEnabled;

bool bDone;

long nCallsInProgress;

IUnknown *pPrimaryObject;


bool bRootOfStream;

bool bHappy;

// interface methods deleted for clarity


interception and proxies
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
apartments in windows 2000
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
contexts apartments and synchronizations summary
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
contexts apartments and synchronizations summary 2
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
threading terminology
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
com threading
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
neutral threading model
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
neutral threading model 2
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…)
neutral vs both almost identical
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
neutral vs both yet different
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
threading recommendations
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!
apartment components
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
free components
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
both components
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
neutral components
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
server components
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
server components 2
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
server components 3
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
asp components
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
wrap up
Wrap Up
  • COM+ improvements
  • Threading terminology
  • Neutral threading model
  • Threading model recommendations
  • Server components